rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rdiff-backup-users] Filechange during backup


From: Maarten Bezemer
Subject: RE: [rdiff-backup-users] Filechange during backup
Date: Fri, 7 Jan 2005 12:31:05 +0100 (CET)

Hi,

On Fri, 7 Jan 2005, Olav Langeland wrote:

> maybe I should give some more details. Backupserver is Linux with LVM,
> clients are FreeBSD with just straight /var, /local etc. mounted dirs.
> rdiff-backup version is v0.12.7. I was hoping to backup /var and include
> all current logs in that backuprun. 

While this seems OK for logfiles that do not change internally but are
appended only, it is quite hard to determine whether this is the case, or
the internal contents have changed, too.

Example 1: /var/log/syslog
With this file, it's OK to ignore the fact that, after starting transfer
of the data, new data has been appended to the logfile.

Example 2: /some/database/table.db
When no guarantee can be given that this file will not be modified during
backup, it is a bad thing (tm) to have some illegal state in the backup
tree. Say the file is 1MB, rdiff-backup has transfered 250KB, and then the
file is changed (updated at offset 10,000 and at offset 800,000 and some
data appended). What to do next? The only logical answer would be: bail
out.

For databases, other tools exist to make backups. For log files... you
could use tar to create a snapshot of the currently active log files just
before running rdiff-backup. But hey, if log files are that important, you
shouldn't rely on rdiff-backup but have them delivered to some other
remote loghost as well. If you lose /var on those boxes and need to
restore from an rdiff-backup snapshot, you'd have lost the most recent
data anyway. While there's a slight difference between losing a day's and
losing a week's log files, if losing log files is a problem, you're in
trouble no matter how much data is lost.

Regards,
 Maarten Bezemer





reply via email to

[Prev in Thread] Current Thread [Next in Thread]