Rsync and opened files

[Tony Abernethy]

The short answer is "It depends"

Egoitz Aurrekoetxea wrote:
> 
> Hello,
> 
> I'm trying to determine if rsync is a sure method of backing 
> up servers (Linux and Windows) whose files are constantly 
> being accesed and are not able to be stoped they're services 
> for backing up purposes... I would use it over ssh for making 
> incremental backups... in my tests seem to always have worked 
> backing up from a debian server to the copy server that runs 
> debian too...  I'm using the next :
> 
> OPTS="--force --ignore-errors --delete --backup 
> --backup-dir=/home/ramattack/pruebas-rsync/$BACKUPDIRMES/$dia -avz"
> 
> rsync $OPTS $BDIR 
> /home/ramattack/pruebas-rsync/$BACKUPDIRMES/imagen-copia
> 
> BDIR is source I want to backup and 
> /home/ramattack/pruebas-rsync....... is the destination...
> 
> could this copy correctly opened files? Normally I will use 
> it for backing up linux machines normally... and the backup 
> server will be of course a linux machine (debian machine). 
> but how does it behave with linux machines?
> 
> P.D. I have googled and searched over there but all posts 
> I've find are old... and I wanted to have a recent answer.
> 
> Thanks a lot mates!!!
> __
I can speak only of my own experience.
The standard caveats apply. It depends and YMMV.

Backing up live (and in-use) MySQL databases seems to work OK.
The file being open is itself somewhat irrelevant.
You can, with a bit of difficulty, do a backup of only closed
files which is very unusable. Difficult, but not very.
What matters is that the backup you copy is usable for your
intended/needed purposes. 
Poor and buggy can be much much better than nothing.

In my own case, it's really more a case of needing a "local"
access to recent info from remote databases than backup per se.
This means that if I do run into a problem, I just run another
rsync and put things back consistent. Almost no problems,
particularly where it matters. (even without CHECK TABLES).
To further decrease the window of opportunity for mother
nature to do its thing, I run back-to-back rsyncs to that
the window when stuff is changing is quite small.

Note: This style would NEVER be "recommended practice".
This depends in large part on the nature of MyISAM
database tables and the fact that on standard MySQL,
readers and writers DO INTERFERE WITH EACH OTHER.
(never thought that was an advantage, did you? ;-)

This also depends on Unix (or Linux) file locking semantics.
Basically, Unix file locks work only with other things
that happen to use the same locking machinery.
Anything can totally ignore what other things call locked.
In particular, LOCK TABLES is ignored by rsync.

Windows has different semantics. Very different.
In particular, best I can tell, the directory entry
is written with timestamp and file size.
...
...
...
sometime later, the contents of the file 
might actually come dribbling in.

I back up Samba home directories at 1:11 AM  
when reasonable users Should be home asleep.
I play some fun&games with multiple backups at 2:22 and 3:33
(gotta love hard links   --- as well as usable soft links)

Assuming a short break in accessibility is tolerable, I'd
1) run rsync to the backup
2) stop the server
3) run rsync to the backup (should be much much faster now)
4) restart the server