Backup Central

I have a 1GB Truecrypt file that I am trying to backup, however,
Rdiff-backup isn't identifying it as a changed file and therefore skips
it. When i run the compare, it says "metadata the same, data changed",
(which I expect) but why isn't rdiff-backup actually backing up the
file? I'm using a volume shadow copy on windows, so it shouldn't be a
locking issue. Other "normal" files in the same directories are backed
up just fine so the setup works, just not with this one file.

How does Rdiff identify changes that trigger backup? I know the file
times/file size will not change since it's a fixed size 1GB container
and Truecrypt purposely doesn't update file timestamps, but the hash
will change as the contents will change.

Is there any way to force Rdiff to use a hash compare for difference
triggering? I looked over the manual, and nothing seems to be what I'm
looking for. Whatever the default comparison method, it's not catching
changes to this file [Firefox_encrypted_profiles.tcdsk].

Here's the commands & output from 2 steps I'm running (minus all the
volumeshadow setup commands):
[backup]
rdiff-backup.exe --backup-mode -v8 --no-acls --no-hard-links
"X:/Documents and Settings/myUsername/Application Data/Mozilla/Firefox"
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store >>
rdiffBackup_log.txt 2>&1

[compare]
rdiff-backup.exe --backup-mode -v8 --no-acls --no-hard-links
--compare-hash "X:/Documents and Settings/myUsername/Application
Data/Mozilla/Firefox"
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store >>
rdiffBackup_log.txt 2>&1


******************************************************************************
**** BACKUP STEP OUTPUT
*****************************************************
******************************************************************************
Rdiff-backup started at Tue 03/22/2011 17:12:14.97 error level 0
Using rdiff-backup version 1.3.3
Hardlinks disabled by default on Windows
Unable to import module xattr.
Extended attributes not supported on filesystem at X:/Documents and
Settings/myUsername/Application Data/Mozilla/Firefox
POSIX ACLs test skipped. rdiff-backup run with --no-acls option.
Windows ACLs test skipped. rdiff-backup run with --no-acls option.
-----------------------------------------------------------------
Detected abilities for source (read only) file system:
Access control lists Off
Extended attributes Off
Windows access control lists Off
Case sensitivity Off
Escape DOS devices On
Escape trailing spaces On
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Making directory
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/5-_
a.snapshot.gz
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/5-_
a.snapshot.gz
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/uni?
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/uni?
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/:\"
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/A
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/a
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/foo
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/foo
Making directory
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/hl
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/hardlinked_file1
Hard linking
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/hl/hardlinked_file2
to
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/hardlinked_file1
Directories on file system at
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0
are not fsyncable.
Assuming it's unnecessary.
Unable to import module xattr.
Extended attributes not supported on filesystem at
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0
POSIX ACLs test skipped. rdiff-backup run with --no-acls option.
Windows ACLs test skipped. rdiff-backup run with --no-acls option.
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/dir_inc_check
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/dir_inc_check
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/regfile
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/regfile
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/high_perms_file
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/high_perms_dir
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/high_perms_file
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/high_perms_dir
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/symlinked_file1
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/symlinked_file1
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/foo
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0/foo
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0
Removing directory
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/rdiff-backup.tmp.0
-----------------------------------------------------------------
Detected abilities for destination (read/write) file system:
Ownership changing Off
Hard linking N/A
fsync() directories Off
Directory inc permissions Off
High-bit permissions On
Symlink permissions Off
Extended filenames On
Windows reserved filenames On
Access control lists Off
Extended attributes Off
Windows access control lists Off
Case sensitivity Off
Escape DOS devices On
Escape trailing spaces On
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Backup: escape_dos_devices = 0
Backup: escape_trailing_spaces = 0
Enabled use_compatible_timestamps
Symbolic links excluded by default on Windows
Writing mirror marker
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/current_mirror.2011-03-22T17-12-16-05-00.data
Starting increment operation X:/Documents and
Settings/myUsername/Application Data/Mozilla/Firefox to
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store
Writing mirror_metadata diff
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/mirror_metadata.2011-03-22T12-51-45-05-00.diff
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/mirror_metadata.2011-03-22T12-51-45-05-00.snapshot.gz
Deleting
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/current_mirror.2011-03-22T12-51-45-05-00.data
Cleaning up
Touching
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data/error_log.2011-03-22T17-12-16-05-00.data
Rdiff-backup process finished at Tue 03/22/2011 17:12:18.97 error level 0


******************************************************************************
**** COMPARE STEP OUTPUT
*****************************************************
******************************************************************************
Rdiff-backup started at Tue 03/22/2011 17:11:21.53 error level 0
Using rdiff-backup version 1.3.3
Using mirror root directory
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store
Hardlinks disabled by default on Windows
Unable to import module xattr.
Extended attributes not supported on filesystem at
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data
POSIX ACLs test skipped. rdiff-backup run with --no-acls option.
Windows ACLs test skipped. rdiff-backup run with --no-acls option.
-----------------------------------------------------------------
Detected abilities for
\\NASserver\myUsername\PC_BACKUP\Rdiff_Backups\encrypted_store/rdiff-backup-data
(read only) file system:
Access control lists Off
Extended attributes Off
Windows access control lists Off
Case sensitivity Off
Escape DOS devices On
Escape trailing spaces On
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Backup: escape_dos_devices = 0
Backup: escape_trailing_spaces = 0
Enabled use_compatible_timestamps
Symbolic links excluded by default on Windows
Successful compare: .
metadata the same, data changed: Firefox_encrypted_profiles.tcdsk
Successful compare: profiles.ini
Cleaning up
Rdiff-backup process finished at Tue 03/22/2011 17:17:20.53 error level 0





_______________________________________________
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

Scott Jilek wrote:
How does Rdiff identify changes that trigger backup? I know the file
times/file size will not change since it's a fixed size 1GB container
and Truecrypt purposely doesn't update file timestamps, but the hash
will change as the contents will change.

That's the problem, rdiff-backup uses the file size and mtime. Both of
which don't change here. The same happens when you open Microsoft Excel
files without saving them: the content changes, but Excel resets the
mtime back to the old value.

Is there any way to force Rdiff to use a hash compare for difference
triggering?

No, there isn't. I asked for exactly this a few weeks ago and didn't get
a reply.

-- Remy


_______________________________________________
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

tis 2011-03-22 klockan 17:48 -0500 skrev Scott Jilek:
Is there any way to force Rdiff to use a hash compare for difference
triggering? I looked over the manual, and nothing seems to be what I'm
looking for.

Might the option --compare-hash be what you are looking for?

// Andreas

_______________________________________________
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

Andreas Olsson wrote:
Might the option --compare-hash be what you are looking for?

That's for comparing the source and the backup. What is needed here is a
way to tell rdiff-backup that it should not only check the file size and
mtime, but also a hash of the content *while backing up*.

-- Remy


_______________________________________________
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

I've tried adding the "--compare-hash" switch. The MAN page isn't
specific about the function of --compare-hash, however it appears to be
only for VERIFICATION and not for candidate IDENTIFICATION, as causes
rdiff to simply show a report telling me this file is not in sync. When
I use that switch no backups occur from what I can tell as no increments
are created.

Is there some way to explicitly force Rdiff to create a backup of
specific files? What am I missing, because this seems like a huge gap
in functionality if it's only using file timestamps.


Is there any way to force Rdiff to use a hash compare for difference
triggering? I looked over the manual, and nothing seems to be what I'm
looking for.

Might the option --compare-hash be what you are looking for?

// Andreas




_______________________________________________
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 2011-03-24 06:29, Scott Jilek wrote:
Is there any way to force Rdiff to use a hash compare for difference
triggering? I looked over the manual, and nothing seems to be what I'm
looking for.

I've tried adding the "--compare-hash" switch. The MAN page isn't specific
about the function of --compare-hash, however it appears to be only for
VERIFICATION and not for candidate IDENTIFICATION, as causes rdiff to simply
show a report telling me this file is not in sync. When I use that switch no
backups occur from what I can tell as no increments are created.

Is there some way to explicitly force Rdiff to create a backup of specific
files? What am I missing, because this seems like a huge gap in
functionality if it's only using file timestamps.

I guess it would be nice to have an option to make rdiff-backup identify
changed files by checksum/hash. That being said, I think I wouldn't want to
use it for anything, because it would be extremely slow. It would need to
read all files from start to end, while hashing them, at each backup run.
For a large backup repository with, say, 500 GB worth of files, the backup
would take more than an hour, even if not a single file changed (assuming
100 MB/s read and hashing speed).

By the way, rsync also wouldn't consider that truecrypt container as
"changed", by default - you would need to add the '-c' option. And maybe
that's the best way to handle this: Exclude the truecrypt container(s) from
your rdiff-backup, and instead use rsync -c for that.
Alternatively you could 'touch' the truecrypt container just before the
backup, so that the modification timestamp gets changed, and rdiff-backup
will pick it up (but then it would create a diff every time, which would
take even longer than the 'rsync -c' method - but maybe you really want the
history of that file...).

Patrick.

- --
Key ID: 0x86E346D4 http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Ki1gACgkQyYHmhobjRtS4OQCeP3mrV9Ar/MGX19OR8ilq9CPo
q1wAn3CZlhalO3XuN0nVttSERzxlMRHk
=10E2
-----END PGP SIGNATURE-----

_______________________________________________
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/23/2011 01:42 PM, Remy Blank wrote:
Scott Jilek wrote:
How does Rdiff identify changes that trigger backup? I know the file
times/file size will not change since it's a fixed size 1GB container
and Truecrypt purposely doesn't update file timestamps, but the hash
will change as the contents will change.

That's the problem, rdiff-backup uses the file size and mtime. Both of
which don't change here. The same happens when you open Microsoft Excel
files without saving them: the content changes, but Excel resets the
mtime back to the old value.

Linux systems that use prelink have that problem for binary executables
and libraries. The first time a new file is prelinked, data is
appended, changing the size. Subsequent prelinks change the data, but
the size stays the same. In all cases, the original modification time
is preserved. Fortunately, a restored binary with an out-of-date
prelink will still run, just be a little slower to start while the
run-time linker does it's work. So, there's no serious harm done, and
the next prelink run will clean everything up.

The place that really bites me is when I use rsync to update the offline
copy of my rdiff-backup repository. Those two copies _have_ to match
exactly or rdiff-backup will complain about checksum errors. What my
script has to go through to avoid using rsync's expensive "--checksum"
test on every file in the repository gets really, really ugly.

--
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

On 24/03/2011 00:07, Patrick Nagel wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 2011-03-24 06:29, Scott Jilek wrote:
Is there any way to force Rdiff to use a hash compare for difference
triggering? I looked over the manual, and nothing seems to be what I'm
looking for.
I've tried adding the "--compare-hash" switch. The MAN page isn't specific
about the function of --compare-hash, however it appears to be only for
VERIFICATION and not for candidate IDENTIFICATION, as causes rdiff to simply
show a report telling me this file is not in sync. When I use that switch no
backups occur from what I can tell as no increments are created.

Is there some way to explicitly force Rdiff to create a backup of specific
files? What am I missing, because this seems like a huge gap in
functionality if it's only using file timestamps.
I guess it would be nice to have an option to make rdiff-backup identify
changed files by checksum/hash. That being said, I think I wouldn't want to
use it for anything, because it would be extremely slow. It would need to
read all files from start to end, while hashing them, at each backup run.
For a large backup repository with, say, 500 GB worth of files, the backup
would take more than an hour, even if not a single file changed (assuming
100 MB/s read and hashing speed).

By the way, rsync also wouldn't consider that truecrypt container as
"changed", by default - you would need to add the '-c' option. And maybe
that's the best way to handle this: Exclude the truecrypt container(s) from
your rdiff-backup, and instead use rsync -c for that.
Alternatively you could 'touch' the truecrypt container just before the
backup, so that the modification timestamp gets changed, and rdiff-backup
will pick it up (but then it would create a diff every time, which would
take even longer than the 'rsync -c' method - but maybe you really want the
history of that file...).

Patrick.

I would echo the suggestion to touch the file. You can download a free
touch.exe program from the net. I use it with -m option in a similar
case to force rdiff-backup (via TimeDicer) to pick up a vmdk file.

Dominic

_______________________________________________
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

Unfortunately, I can't just touch the file because it's in use and
locked by the truecrypt process.

Is there any plan to add the rsync -c option to rdiff-backup to force
"always checksum" for files like this. Obviously it wouldn't be used in
most cases, but for known special files like this where timestamps
aren't used, it really is the only option.

I could try to install one of the windows rsync variants in this case,
but the whole idea of a practical backup process to me is getting
multiple snapshots in time, whereas rsync only gives me efficient
mirroring. I'm not too keen on mirroring as a backup strategy, because
corrupted files completely destroy the usefulness of mirroring. If it's
bad in the source, it becomes bad in the singular backup as soon as the
backup process runs and then you have no recovery option. With Rdiff, I
can go back in time to just before the corruption occurred and restore
the file to the last know working time. As far as I'm concerned, simple
mirroring is not a safe method of backup

-Scott


On 3/24/2011 8:02 AM, Dominic Raferd wrote:
On 24/03/2011 00:07, Patrick Nagel wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 2011-03-24 06:29, Scott Jilek wrote:
Is there any way to force Rdiff to use a hash compare for difference
triggering? I looked over the manual, and nothing seems to be
what I'm
looking for.
I've tried adding the "--compare-hash" switch. The MAN page isn't
specific
about the function of --compare-hash, however it appears to be only for
VERIFICATION and not for candidate IDENTIFICATION, as causes rdiff
to simply
show a report telling me this file is not in sync. When I use that
switch no
backups occur from what I can tell as no increments are created.

Is there some way to explicitly force Rdiff to create a backup of
specific
files? What am I missing, because this seems like a huge gap in
functionality if it's only using file timestamps.
I guess it would be nice to have an option to make rdiff-backup identify
changed files by checksum/hash. That being said, I think I wouldn't
want to
use it for anything, because it would be extremely slow. It would
need to
read all files from start to end, while hashing them, at each backup
run.
For a large backup repository with, say, 500 GB worth of files, the
backup
would take more than an hour, even if not a single file changed
(assuming
100 MB/s read and hashing speed).

By the way, rsync also wouldn't consider that truecrypt container as
"changed", by default - you would need to add the '-c' option. And maybe
that's the best way to handle this: Exclude the truecrypt
container(s) from
your rdiff-backup, and instead use rsync -c for that.
Alternatively you could 'touch' the truecrypt container just before the
backup, so that the modification timestamp gets changed, and
rdiff-backup
will pick it up (but then it would create a diff every time, which would
take even longer than the 'rsync -c' method - but maybe you really
want the
history of that file...).

Patrick.

I would echo the suggestion to touch the file. You can download a free
touch.exe program from the net. I use it with -m option in a similar
case to force rdiff-backup (via TimeDicer) to pick up a vmdk file.

Dominic

_______________________________________________
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


-----

Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1498/3524 - Release Date: 03/23/11



_______________________________________________
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 24/03/2011 17:31, Scott Jilek wrote:
Unfortunately, I can't just touch the file because it's in use and
locked by the truecrypt process.

Are you sure? I tried this and it worked for me with a truecrypt file in
use.

Is there any plan to add the rsync -c option to rdiff-backup to force
"always checksum" for files like this. Obviously it wouldn't be used in
most cases, but for known special files like this where timestamps
aren't used, it really is the only option.

rdiff-backup development is stalled, sorry

I could try to install one of the windows rsync variants in this case,
but the whole idea of a practical backup process to me is getting
multiple snapshots in time, whereas rsync only gives me efficient
mirroring. I'm not too keen on mirroring as a backup strategy, because
corrupted files completely destroy the usefulness of mirroring. If it's
bad in the source, it becomes bad in the singular backup as soon as the
backup process runs and then you have no recovery option. With Rdiff, I
can go back in time to just before the corruption occurred and restore
the file to the last know working time. As far as I'm concerned, simple
mirroring is not a safe method of backup

I agree, rdiff-backup is practically perfect. But when you hit a
limitation you will have to workaround.

Dominic http://www.timedicer.co.uk

_______________________________________________
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

Hi Scott,

On Thu, 24 Mar 2011, Scott Jilek wrote:

Unfortunately, I can't just touch the file because it's in use and locked by
the truecrypt process.

In that case, rdiff-backup probably won't be able to open it to back it up
either? You'll probably get an error message that the file can't be opened
when you try to back it up? And even if you could back it up, you'd
probably get an inconsistent and hence useless/corrupt backup if truecrypt
is really writing to the encrypted filesystem while a backup or rsync is
in progress.

I could try to install one of the windows rsync variants in this case,
but the whole idea of a practical backup process to me is getting
multiple snapshots in time, whereas rsync only gives me efficient
mirroring. I'm not too keen on mirroring as a backup strategy, because
corrupted files completely destroy the usefulness of mirroring. If it's
bad in the source, it becomes bad in the singular backup as soon as the
backup process runs and then you have no recovery option. With Rdiff, I
can go back in time to just before the corruption occurred and restore
the file to the last know working time. As far as I'm concerned, simple
mirroring is not a safe method of backup

You could rsync the truecrypt file to somewhere else, if that works, and
then back it up with a separate rdiff-backup command?

Or alternatively create a VSS snapshot and back that up? But Truecrypt
would probably need to be patched to be a VSS writer, or to not
reset the timestamp when it writes to the file, because you probably
can't change the timestamp in the VSS snapshot, it being a snapshot and
hence read-only.

Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chris+sig < at > qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |

_______________________________________________
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 3/24/2011 3:42 PM, Chris Wilson wrote:
Hi Scott,

On Thu, 24 Mar 2011, Scott Jilek wrote:

Unfortunately, I can't just touch the file because it's in use and
locked by the truecrypt process.

In that case, rdiff-backup probably won't be able to open it to back
it up either? You'll probably get an error message that the file can't
be opened when you try to back it up? And even if you could back it
up, you'd probably get an inconsistent and hence useless/corrupt
backup if truecrypt is really writing to the encrypted filesystem
while a backup or rsync is in progress.

Correct, I am utilizing Volume Shadow copies to get around the file
locking. I tried using a windows compiled touch, but it wouldn't work
on the Truecrypt volume while it was mounted (which is why I started
with VSS in the first place).
I could try to install one of the windows rsync variants in this
case, but the whole idea of a practical backup process to me is
getting multiple snapshots in time, whereas rsync only gives me
efficient mirroring. I'm not too keen on mirroring as a backup
strategy, because corrupted files completely destroy the usefulness
of mirroring. If it's bad in the source, it becomes bad in the
singular backup as soon as the backup process runs and then you have
no recovery option. With Rdiff, I can go back in time to just before
the corruption occurred and restore the file to the last know working
time. As far as I'm concerned, simple mirroring is not a safe method
of backup

You could rsync the truecrypt file to somewhere else, if that works,
and then back it up with a separate rdiff-backup command?

Or alternatively create a VSS snapshot and back that up? But Truecrypt
would probably need to be patched to be a VSS writer, or to not reset
the timestamp when it writes to the file, because you probably can't
change the timestamp in the VSS snapshot, it being a snapshot and
hence read-only.

I was thinking along those same lines and planning to mess with that
approach tonight. In my backup script, I figured I'd 1) take a VSS
snapshot of truecrypt file, 2) make a copy of the truecrypt volume file
from the VSS snapshot to some temporary location, 3) touch that copied
file & 4) run an rdiff-backup command targeted only on that temp file.

This process would be a bit of a hack, but I think it *should* work.
The downsides are it temporarily takes up some free space, and extra
time in write cycles, but if it works, I can live with it. Granted,
disc space is cheap & the backup runs over night, but I was just hoping
to let Rdiff handle everything.

-Scott
Cheers, Chris.



_______________________________________________
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-03-26 08:27, Patrick Nagel wrote:
If that TrueCrypt volume is mounted anyway, why don't you just
rdiff-backup the files inside it into another TrueCrypt volume on the
backup system?

Patrick.
Hi Scott,

Hm... I think I might have used that phone's e-mail client in a wrong way
there...

- --
Key ID: 0x86E346D4 http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2NT+4ACgkQyYHmhobjRtSangCghmIWtVXzHuPkLmaDhtZZZR9L
B+YAnRc3w7Pt3lrd9QmEAUh6ItPTDvTr
=7iSd
-----END PGP SIGNATURE-----

_______________________________________________
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