db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6399) clarify backup section in Derby Server and Administration Guide regarding connecting to the backed up db
Date Tue, 05 Nov 2013 22:40:18 GMT

    [ 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)

Mime
View raw message