You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kim Haase (JIRA)" <ji...@apache.org> on 2013/11/01 19:21:18 UTC

[jira] [Updated] (DERBY-6399) clarify backup section in Derby Server and Administration Guide regarding connecting to the backed up db

     [ https://issues.apache.org/jira/browse/DERBY-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kim Haase updated DERBY-6399:
-----------------------------

    Attachment: DERBY-6399.zip
                DERBY-6399.stat
                DERBY-6399.diff

Attaching DERBY-6399.diff, DERBY-6399.stat, and DERBY-6399.zip, with changes as follows:

M       src/adminguide/tadminlog800206.dita
M       src/adminguide/cadminhubbkup01.dita
M       src/adminguide/cadminrollforward.dita

Please let me know what further changes are needed. Thanks!

> 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
>            Reporter: Myrna van Lunteren
>            Assignee: Kim Haase
>            Priority: Minor
>         Attachments: 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)