Gary,
It is always a good practice to test the whole solution backup/restore.
So nothing is better than testing a restore, actually it should be a
periodic procedure.
As for the validity of the file usually is delegated to the operating
system.
If you want to check it yourself you may create an
you can use checksum to make sure there are not corruption in the file
On Wed, Nov 7, 2012 at 6:39 PM, Claudio Nanni claudio.na...@gmail.comwrote:
Gary,
It is always a good practice to test the whole solution backup/restore.
So nothing is better than testing a restore, actually it should be
2012/11/7 Ananda Kumar anan...@gmail.com
you can use checksum to make sure there are not corruption in the file
That would work for the file integrity itself not for the data integrity
_in_ the file.
As Claudio suggested, probably going thru the whole recovery process from
time to time is
In the past when I used mysqldump, I used a slave database for backups and
periodically testing restores.
My process for testing:
- Stop the slave process (so the db doesn't get updated).
- Run the backup.
- Create restore_test database.
- Restore the backup to the restore_test database.
- Use
A variant on that...
1. pre-validate slave's consistency using pt-table-checksum
2. dump slave, wipe clean, restore
3. RE-validate slave's consistency using pt-table-checksum
-Original Message-
From: Stillman, Benjamin [mailto:bstill...@limitedbrands.com]
Sent: Wednesday, November 07,
Hi everybody,
it looks like the reason for the problem was me not handling string arguments
properly (I did not use the provided lengths, but relied on string being
null-terminated, it's in the doc, but ...). It seems this became a problem
specifically in the parallel situation, misleading me
