db-derby-dev mailing list archives

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

     [ 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-2.zip
                DERBY-6399-2.diff

Thanks, Myrna, for the careful review! I am attaching DERBY-6399-2.diff and DERBY-6399-2.zip,
with the changes you suggested. (I also added a mention of the NOWAIT version to the paragraph
on the plain BACKUP call, to parallel the mention of both versions in the following paragraph.)

Please let me know if further changes are needed.

> 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