As a final backup/recovery strategy, you can create a hot failover. Note that using hot failovers requires your application to be able to specify its environment home directory at application startup time. Most application developers allow the environment home directory to be identified using a command line option or a configuration or properties file. If your application has its environment home hard-coded into it, you cannot use hot failovers.
You create a hot failover by periodically backing up your database to an alternative location on disk. Usually this alternative location is on a separate physical drive from where you normally keep your database, but if multiple drives are not available then you should at least put the hot failover on a separate disk partition.
You failover by causing your application to reopen its environment using the failover location.
Note that a hot failover should not be used as a substitute for backing up and archiving your data to a safe location physically remote from your computing environment. Even if your data is spread across multiple physical disks, a truly serious catastrophe (fires, malevolent software viruses, faulty disk controllers, and so forth) can still cause you to lose your data.
To create and maintain a hot failover:
Copy all log files (*.jdb) from your environment
directory to the location where you want to keep your failover. Either an
offline or a hot backup can be used for this purpose, but typically a hot
failoveris initially created by taking an offline backup of your database.
This ensures that you have captured the contents of your in-memory cache.
If you are using subdirectories to store your log files, then you must backup the subdirectories, making sure to keep log files in the subdirectory in which JE placed them. For information on using subdirectories to store your log files, see the Getting Started with Berkeley DB, Java Edition guide.
Periodically copy to your failover directory any log files that were changed or created since the time of your last copy. Most backup software is capable of performing this kind of an incremental backup for you.
Note that the frequency of your incremental copies determines the amount of data that is at risk due to catastrophic failures. For example, if you perform the incremental copy once an hour then at most your hot failover is an hour behind your production database, and so you are risking at most an hours worth of database changes.
Remove any *.jdb files from the hot failover directory that have been removed or
renamed to .del files in the primary directory. This is not necessary for
consistency, but will help to reduce disk space consumed by the hot failover.