Performing Backups
Prev | Chapter 7. Backing up and Restoring Berkeley DB Java Edition Applications | Next

## Performing Backups

This section describes how to backup your JE database(s) such that catastrophic recovery is possible for non-transactional applications. Note that this same material is repeated in the Berkeley DB Java Edition Getting Started with Transaction Processing guide, but for transactional applications. If you are writing transactional applications, you may want to skip the rest of this chapter and go straight to that book.

To backup your database, you can either take a hot backup or an offline backup. A hot backup is performed while database write operations are in progress.

Do not confuse hot and offline backups with the concept of a full and incremental backup. Both a hot and an offline backup are full backups – you back up the entire database. The only difference between them is how much of the contents of the in-memory cache are contained in them. On the other hand, an incremental backup is a backup of just those log files modified or created since the time of the last backup. Most backup software is capable of performing both full and incremental backups for you.

### Performing a Hot Backup

To perform a hot backup of your JE databases, copy all log files (`*.jdb` files) from your environment directory to your archival location or backup media. The files must be copied in alphabetical order (numerical in effect). You do not have to stop any database operations in order to do this.

To make this process a bit easier, you may want to make use of the `DbBackup` helper class. See Using the DbBackup Helper Class for details.

Note that any modifications made to the database since the time of the last environment sync are not guaranteed to be contained in these log files. In this case, you may want to consider running an offline backup in order to guarantee the availability of all modifications made to your database.

### Performing an Offline Backup

An offline backup guarantees that you have captured the database in its entirety, including all contents of your in-memory cache, at the moment that the backup was taken. To do this, you must make sure that no write operations are in progress and all database modifications have been written to your log files on disk. To obtain an offline backup:

1. Stop writing your databases.

2. Run `Environment.sync()` so as to ensure that all database modifications are written to disk. Note that cleanly closing your environment will also ensure that all database modifications are written to disk.

3. Copy all log files (`*.jdb`) from your environment directory to your archival location or backup media. To make this process a bit easier, you may want to make use of the `DbBackup` helper class. See the next section for details.

You can now resume normal database operations.

### Using the DbBackup Helper Class

In order to simplify backup operations, JE provides the `DbBackup` helper class. This class stops and restarts JE background activity in an open environment. It also lets the application create a backup which can support restoring the environment to a specific point in time.

Because you do not have to stop JE write activity in order to take a backup, it is usually necessary to examine your log files twice before you decide that your backup is complete. This is because JE may create a new log file while you are running your backup. A second pass over your log files allows you to ensure that no new files have been created and so you can declare your backup complete.

For example:

     time    files in                    activity
             environment

      t0     000000001.jdb     Backup starts copying file 1
             000000003.jdb
             000000004.jdb

      t1     000000001.jdb     JE log cleaner migrates portion of file 3 to newly
             000000004.jdb     created file 5 and deletes file 3. Backup finishes
             000000005.jdb     file 1, starts copying file 4. Backup MUST include
                               file 5 for a consistent backup!

      t2     000000001.jdb     Backup finishes copying file 4, starts and finishes
             000000004.jdb     file 5, has caught up. Backup ends.
             000000005.jdb

`DbBackup` works around this problem by defining the set of files that must be copied for each backup operation, and freezes all changes to those files. The application can copy that defined set of files and finish operation without checking for the ongoing creation of new files. Also, there will be no need to check for a newer version of the last file on the next backup.

In the example above, if `DbBackup` was used at t0, the application would only have to copy files 1, 3 and 4 to back up. On a subsequent backup, the application could start its copying at file 5. There would be no need to check for a newer version of file 4.

The following code fragment illustrates this class' usage:

    package je.gettingStarted;

    ...
    import com.sleepycat.je.util.DbBackup;
    ...

        Environment env = new Environment(...);
        DbBackup backupHelper = new DbBackup(env);

        // Find the file number of the last file in the previous backup
        // persistently, by either checking the backup archive, or saving
        // state in a persistent file.
        long lastFileCopiedInPrevBackup =  ...

        // Start backup, find out what needs to be copied.
        backupHelper.startBackup();
        try {
            String[] filesForBackup =
                 backupHelper.getLogFilesInBackupSet(lastFileCopiedInPrevBackup);

            // Copy the files to archival storage.
            myApplicationCopyMethod(filesForBackup)
            // Update our knowlege of the last file saved in the backup set,
            // so we can copy less on the next backup
            lastFileCopiedInPrevBackup = backupHelper.getLastFileInBackupSet();
            myApplicationSaveLastFile(lastFileCopiedInBackupSet);
        }
        finally {
            // Remember to exit backup mode, or all log files won't be cleaned
            // and disk usage will bloat.
           backupHelper.endBackup();
       }

Prev | Up | Next
Chapter 7. Backing up and Restoring Berkeley DB Java Edition Applications | Home | Performing Catastrophic Recovery