[
https://issues.apache.org/jira/browse/DERBY-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814345#comment-13814345
]
Mike Matrigali commented on DERBY-6399:
---------------------------------------
cadminhubbkup01.html:
change this line to mention both versions of the call, to parallel how they are
referred to later:
Use the SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE procedure
if you want to make it possible to perform a roll-forward recovery of a damaged
database. See Roll-forward recovery for details.
lets make the following stronger (please feel free to clean up the language):
old:An attempt to access the backup directly could invalidate the backup
new: An attempt to access the backup directly will invalidate the backup. The
result could include a corrupted database, missing data, errors during
subsequent attempt at restore, or db corruption errors only encountered
once the restored database is being used.
cadminrollforward.html:
no comments.
> clarify backup section in Derby Server and Administration Guide regarding
> connecting to the backed up db
> --------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6399
> URL: https://issues.apache.org/jira/browse/DERBY-6399
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.10.1.1
> Reporter: Myrna van Lunteren
> Assignee: Kim Haase
> Priority: Minor
> Attachments: DERBY-6399-2.diff, DERBY-6399-2.zip, DERBY-6399.diff,
> DERBY-6399.stat, DERBY-6399.zip
>
>
> 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';
--
This message was sent by Atlassian JIRA
(v6.1#6144)
