Backup Central

We just started using rdiff rather than rsync. Everything seems to be running OK so far, but I found what may be a problem in the future.

This is our basic code:
rdiff-backup.exe -v5 --force --exclude-globbing-filelist exclude.filter 'Source' 'Destination'

Lets say the source is C:/mysql
and the destination is D:/backup

It all runs fine and does what it's supposed to - but I noticed that if I delete D:/backup/mysql/bin - I can't get rdiff to re-create it. rdiff compares the meta-data and doesn't seem to see that the backup folder/files are missing.

Am I missing an option or is there something to check or compare the files not just the meta-data?

I have not used this option personally, but:

--verify
This is short for --verify-at-time now

--verify-at-time now
Check all the data in the repository at the given time by computing the SHA1 hash of all the regular files and comparing them with the hashes stored in the metadata file.

Chris

----- Original Message -----
We just started using rdiff rather than rsync. Everything seems to be
running OK so far, but I found what may be a problem in the future.

This is our basic code:
rdiff-backup.exe -v5 --force --exclude-globbing-filelist
exclude.filter 'Source' 'Destination'

Lets say the source is C:/mysql
and the destination is D:/backup

It all runs fine and does what it's supposed to - but I noticed that
if I delete D:/backup/mysql/bin - I can't get rdiff to re-create it.
rdiff compares the meta-data and doesn't seem to see that the backup
folder/files are missing.

Am I missing an option or is there something to check or compare the
files not just the meta-data?

+----------------------------------------------------------------------
|This was sent by mlg < at > ndsys.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------



_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On 03/17/2011 10:26 AM, MikeyG79 wrote:
We just started using rdiff rather than rsync. Everything seems to be running OK so far, but I found what may be a problem in the future.

This is our basic code:
rdiff-backup.exe -v5 --force --exclude-globbing-filelist exclude.filter 'Source' 'Destination'

Lets say the source is C:/mysql
and the destination is D:/backup

It all runs fine and does what it's supposed to - but I noticed that if I delete D:/backup/mysql/bin - I can't get rdiff to re-create it. rdiff compares the meta-data and doesn't seem to see that the backup folder/files are missing.

Am I missing an option or is there something to check or compare the files not just the meta-data?

What you are missing is the manual page warning that you should never write to
mirror directory except with rdiff-backup. Once you've corrupted the backup
by making changes to the mirror, rdiff-backup won't function correctly for any
files that you affected.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Thank you for the quick reply.

running a rdiff-backup -v9 --verfy D:/backup
did not restore the missing files, just gives the following log:
*************************************************

Thu Mar 17 13:26:05 2011 Warning: Could not restore file mysql/bin/bug25714.exe!

A regular file was indicated by the metadata, but could not be
constructed from existing increments because last increment had type
None. Instead of the actual file's data, an empty length file will be
created. This error is probably caused by data loss in the
rdiff-backup destination directory, or a bug in rdiff-backup
Thu Mar 17 13:26:05 2011 Warning: Computed SHA1 digest of mysql/bin/bug25714.exe
da39a3ee5e6b4b0d3255bfef95601890afd80709
doesn't match recorded digest of
a2c333b8f6a7ebc8b9c2c93efc0f3ab45ccd1c5c
Your backup repository may be corrupted!
Thu Mar 17 13:26:05 2011 Warning: Could not restore file mysql/bin/comp_err.exe!

What you are missing is the manual page warning that you should never write to
mirror directory except with rdiff-backup. Once you've corrupted the backup
by making changes to the mirror, rdiff-backup won't function correctly for any
files that you affected.


Wow, guess we're going to switch back to rsync. If rdiff can't create a backup from live files (ie: recreate files in the backup repository that may get erased) it's almost worthless in our situation.

We've been using rsync to keep incremental backups on the clients systems for easy/quick restore. So if part of the full backup gets moved, the backup mechanism needs to be able to re-create that.

On 03/18/2011 06:54 AM, MikeyG79 wrote:
What you are missing is the manual page warning that you should never write to
mirror directory except with rdiff-backup. Once you've corrupted the backup
by making changes to the mirror, rdiff-backup won't function correctly for any
files that you affected.


Wow, guess we're going to switch back to rsync. If rdiff can't create a backup from live files (ie: recreate files in the backup repository that may get erased) it's almost worthless in our situation.

We've been using rsync to keep incremental backups on the clients systems for easy/quick restore. So if part of the full backup gets moved, the backup mechanism needs to be able to re-create that.

An rdiff-backup repository is in essence a large, intricate database, a portion
of which (the mirror) is arranged for easy read-only access. If you run around
randomly deleting or modifying pieces of that database, you'll get results
similar to what would happen if you mangled any other database in that manner.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki