CardBackup Supports Palm OS versions:
- 5.0 and greater.
- 4.0 and greater.
- 3.5 and greater (see below).
CardBackup will run on any Palm OS device that has VFS capability. Officially from Palm
this started with the release of the m500 and m505 (IE, OS4.0). However, since then
3rd party drivers have been made for Handspring devices running mainly Palm OS 3.51.
You can find more information about these drivers at KopsisEngineering.com
CardBackup will run on any Palm OS device that has VFS capability.
This includes but is not limited too:
- ALL Palm devices with expansion cards (Tungsten T/W,m500,m505,m515,m130,m125,etc)
- ALL Sony devices with MemorySticks.
- Handspring devices with third party drivers
- Handera devices that support VFS.
First, if you've just corrupted a single database of an application you should perform a partial restore and only restore the
databases that you have corrupted. If, in fact your handheld is badly corrupted, you should place CardBackup on the card (you've done
that already right) then hard reset your Palm by holding down the "on" button and reseting the handheld. Keep the "on" pressed until
you see the logo screen. Then press up to erase all memory. Then run CardBackup from the card and restore.
You can escape the reset loop typically by holding the "up" button down while performing a reset. It is not wise to continue to run
this way but you should be able to use your handheld and at least delete the offending application that is causing the reset.
Why this happens is that PalmOS sends a "reset" launch code to every application installed on the handheld. If an application
happens to crash when it's sent the reset launch code then you'll get caught in a reset loop. Hold the "up" button down prevents
PalmOS from sending the reset launch code. This has a potential adverse effect on applications that require the launch code to
operate. For instance, Datebook, uses the reset launch code to re-set it's alarms, so after a warm reset your next alarm will not
go off unless you actually run Datebook before it's scheduled. Likewise CardBackup will not perform scheduled backups after a warm reset.
We suggest ResetEmu (can find on Palmgear.com) to help track down applications that are crashing after a reset.
CardBackup will backup all PalmOS databases in the handheld memory. This means pretty much *everything*.
Applications, their data, preferences, etc. In PalmOS, all data is stored as a database. CardBackup will backup
all databases in the handheld's memory.
99% of the time this is because your using some sort of mounting software to mount a directory on your card into Palm
memory. Some of the products that do this are MSMount, PiDirect, and PowerRun. CardBackup needs to know that you
are using mounting software so it will skip these databases (after all the are already on your card). If CardBackup
attempts to back them up it will crash the handheld. To setup CardBackup you can hit the setup button then check
the "using mount software" checkbox and then enter the directory on your card your mounting.
Most of the time this is because you have CardBackup *only* stored on the memory card. PalmOS does not send
alarms to applications stored only on the memory card. We suggest having CardBackup on both the card and the
handheld. This way you're protected from crashes and your scheduled backups will work.
To make a copy of CardBackup on your card. Run CardBackup, press the setup button then press the "Copy CardBackup to Card"
button. You can also make CardBackup your memory cards startup application, meaning everytime you insert the card CardBackup will
automatically run, on the setup screen as well.
Mouting software like MSMount, PiDirect, or PowerRun allow you to "mount" a directory on your card so that
PalmOS thinks it's part of it's internal memory. If you use mounting software you definately need to let
CardBackup know by setting it up on the "setup" screen. To setup CardBackup you can hit the setup button then check
the "using mount software" checkbox and then enter the directory on your card your mounting.
Short Answer: No
Why?
Security. That may sound strange at first but this is the reason. If CardBackup, or any backup software for that matter,
were to encrypt your backup *and* provide for scheduled backups it would need to store your encryption password in the handheld memory so it
could use it to encrypt the backup. This would
cause a security risk because it would be stored in the handheld memory and could potentially be stolen by a person trying to read your data.
We do strongly suggest you encrypt important information on the handheld using third party applications like CryptoPad. This
way the data is already encrypted when CardBackup stores it on the memory card.
Beginning with version 2.0 CardBackup compares the current backup set with the handheld memory and only backs up what has changed. Because of this a typical
scheduled backup will take only about 30-45 seconds. CardBackup is just as fast as other backup solutions. All of them use the Virtual File System PalmOS API
to store information on the memory card.
You are getting full backups. When card backup backs up what has changed it actually adds to/updates the current backup set.
The end result is that every backup listed on the main screen is a full backup as of the date given.
This is different then most PC based incremental backups in which the "backup what's changed" only creates a backup
with literally "what's changed". This method was a throwback to how tapes work and size contraints. In the case of
the PalmOS these limitations don't mean anything anymore. Thus, each backup is a complete set as of the date given.
Starting with the Tungsten3 and TungstenE PalmOne has made significant improvements to the PIM applications (Calendar,Contacts,etc).
To make the improvements they had to change thier database structure for the PIM's. But they had a problem, too many older applications
read and write directly to those old databases. For example, if an application wanted to look up a phone number it would open the
old AddressDB and read directly from it. So, PalmOne has moved all the real PIM information into new databases (shown below) and
have made "fake" databases out of the old ones. The fake database basically allows all those old applications to still read/write to the old
databases. The problem is that there could be conflicts if CardBackup attempts to restore one of these "fake" databases.
PalmOne has asked us to not backup or restore the old "fake" databases. Your data is safely held in the new databases.
| Old Database | New PIM Database(where the data is really stored) |
| AddressDB | Contacts-PAdd |
| DateBookDB | Calendar-PDat |
| TodoDB | Tasks-PTod |
| MemoDB | Memos-PMem |
| 