2 Replies Latest reply: Jun 4, 2013 7:53 PM by user8997135 RSS

    backup compression

      I saw SecondaryConfig.setAllowPopulate and imagine it could be used for backup compression.

      If I only backup the primary dbs and reconstruct the secondary dbs when performing recovery, I can save a lot of disk space and backup time/bandwidth.

      Is the above true and how do I achive that?

      Edited by: user8997135 on Jun 4, 2013 8:38 AM
        • 1. Re: backup compression
          "Andrei Costache, Oracle-Oracle"

          What SecondaryConfig.setAllowPopulate() allows is for a secondary database to be automatically populated, if it is empty. This is useful when you are creating a secondary database at a later time than the primary database and need the secondary to be up-to-date with the primary and contain all the secondary keys that it would have contained if created at the same time with the primary.

          There is no relation between this method and backups. Backups in JE are done by eventually copying all log files (the *.jdb files in the JE environment directory or subdirectories) to the backup location. Performing backups in JE is explained here:
          Performing recovery implies opening the JE environment as normal, which will automatically run JE's normal recovery. This is explained here:

          When backing up, you backup the JE log files which contain all the databases. You cannot selectively choose only some log files or just parts of log files that contain nodes reflecting the primary databases' data. Also, you cannot control the recovery process when opening an environment to make it only recover certain databases.

          You would need to use a different approach outside of the regular backup/recovery processes in JE. You can use DbDump and DbLoad either separately as utilities or programmatically from code to dump only the primary databases to the backup location (the backup environment) and than load them there. When you will need to perform a recovery you will open the backup environment (which will run normal recovery) and than open/create the secondary databases allowing for automatic population.

          Or maybe much more simpler, go along the usual backup process for a JE environment (by doing a hot or offline backup, hence a full backup), and after copying all *.jdb log files from the live environment to the backup environment, open the backup environment, use Environment.truncateDatabase() to empty the secondary databases, followed by a call to Environment.checkpoint() and Environment.cleanLog(), than close the backup environment. This way you will have a backup environment that has the secondary database names, with these secondary databases being empty. They can be created when recovering, after opening the environment, when you will be opening the secondary databases configured with SecondaryConfig.setAllowPopulate(true).
          Note that this approach is not feasible if you implement incremental backups, because the new log files that you copy in to the backup environment will contain entries referring to the secondaries.

          • 2. Re: backup compression
            So the conclusion is I CAN take advantage of that feature to reduce backup size. Although indirectly.
            Maybe devs can think about adding a function to do this. Since file size is a famous critique on bdb. It would be benificial to remove it.

            The nicest thing seems to be something like env.incremental_backup_of_primaryDbs().

            Edited by: user8997135 on Jun 4, 2013 5:51 PM