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: Olav Langeland
Subject: RE: [rdiff-backup-users] Filechange during backup
Date: Tue, 11 Jan 2005 15:15:30 +0100

> -----Original Message-----
> From: Maarten Bezemer [mailto:address@hidden 
> Sent: 7. januar 2005 12:31
> To: Olav Langeland
> Cc: Neil; address@hidden
> Subject: RE: [rdiff-backup-users] Filechange during backup
> 
> 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

Agree. For databases it's either SQL backupclient, or the old
dump-to-file then backup. But I have some logs that for different
reasons I would prefer not to nightly logrotate but still would be nice
to have backed up. 
Reason for the original post was to find out if rdiff-backup had some
workaround to generally ignore files being changed and just continue
backing them up, ofcourse at my own risk. If that is not an option I'll
just have to work something out. 

Regards
Olav Langeland




reply via email to

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