Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
10.10.1.1
-
None
Description
The Derby Server and Administration Guide could clarify better that a backup created using the SYSCS_UTIL.SYSCS_BACKUP_DATABASE is effectively a copy (with the caveats regarding non-logged data).
But when using the SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE the resulting backed up directory is not a full copy of the database, and connecting to it directly could be missing data, and possibly invalidate the backup.
Also, it might be helpful to add an example to the rollforwardrecovery page that is more of a scenario, whereby first the old, perhaps corrupted database, gets renamed, and then a new one is created in its place, but based on the backup and using the logDevice text, maybe something like:
Should a problem have developed with a database, the best approach is to shutdown the original database, rename the original database directory, use the rollForwardRecovery with the logDevice attribute, for instance in a linux shell, if the database wombat was previously backed up to directory /backups:
mv /databases/wombat /databases/brokenwombat
cd /databases
then do the following in ij:
connect 'jdbc:derby:wombat;rollForwardRecoveryFrom=/backups/wombat;logDevice=/databases/brokenwombat';