2000-10-12-21:03:53 Sanjeev Jha:
> This is a critical issue, I think.
Not me, I don't think that at all:-).
> If the file is open and being modified, then if at time "t0" you
> start sending file through rsync, at t1 rsync copied say block-2,
> at t3 while it copying block-10 (say), block-2 get modified and
> whole file end up with a corrupted file. Thus this file is
> inconsistent, right ? And we won't notice that the file being send
> is inconsistent.
This applies to all backup strategies. Once upon a time, people
professed to be rabidly concerned about this one; dump(8) dates from
those ages. Back then, it was taken on faith, as a matter of
religious purity, that all backups had to be perfect, so taking
backups required that systems be made unavailable. The backup
procedure would unmount each filesystem, before backing it up, with
the sole exception of root, which would be backed up while the
system was otherwise idle in single-user mode. Very manual backups
were then, and they didn't happen too often --- weeky rather than
daily --- because they represented a lot of time with the systems
unavailable, so had to be one really after hours, and of course the
systems administrator had to be there for them. Ick.
Somewhere in the '80s, standards shifted. It's recognized that a
backup taken while the system is up and active and files are
potentially being modified is not guaranteed to be perfect, but it's
often good enough, and where more precise guarantees are required,
it's less pain to code them manually around just the files of
specific interest.
If you want an rsync guaranteed safe against modifications, you
could do it various ways. You could e.g. remount the src filesystem
readonly, and change the perms on the files in the dst so nobody
but root can modify them. You only need to "chmod 0" the root of
the dir tree. Then sweep with lsof to make sure nobody has retained
open file handles or cwds, then run the rsync, then make the trees
accessible again.
-Bennett
PGP signature
