On 11/18/2011 11:22 AM, Kim Haase wrote:
On 11/18/11 01:36 PM, Katherine Marsden wrote:
On 11/18/2011 8:42 AM, Spezifikum wrote:
Sorry. I just found the relevant parts quite well documented in the
administration guide. The best solution would be to build something
around "SYSCS_UTIL.SYSCS_BACKUP_DATABASE".
Thank you for thinking about backups and backing up the right way!
Incorrect backup/restore procedures for example relying on a system
backup while the database is active, relying on incremental backups or
often no backup at all is often the first chapter and the final epitaph
of most corrupt Derby database tragedies.
One thing that I think would be good to add to our documentation is the
suggestion to run SYSCS_UTIL.SYSCS_CHECK_TABLE on all the tables of the
database before backing up as sometimes I also see cases
Kathy, it would be great if you could file a doc issue on this -- I
can add it to my plate for the next release. You could make it generic
enough to incorporate any other feedback on the backup documentation.
Thank you Kim,
I filed https://issues.apache.org/jira/browse/DERBY-5508 and in that
issue included some of the possible root causes for backup/restore *fail*:
1) They relied on a operating system backup while the database was not
shutdown or frozen.
2) They unknowingly backed up a corrupt database over their good backup
because there was corruption that was not readily apparent at the time
of the backup. (answer to cliff-hanger sentence above)
3) They relied on incremental backups (even when the database was
shutdown) that did not properly track deletes.
4) They restored to an existing database directory without removing the
old one first.
5) They didn't backup because the Derby backup was not included in the
embedding application''s backup procedure.
6) The embedding application did have a backup/restore procedure but it
made one of the mistakes above.
Hopefully those will help spark ideas for the improved documentation.
Kathey
