Remote backups, reading from and writing to the same file

Pietralla, Siegfried P siegfried.pietralla at
Thu Jan 12 16:16:08 PST 2006

> -----Original Message-----
> From: owner-freebsd-questions at
[mailto:owner-freebsd-questions at] On Behalf Of Hans Nieser
> Sent: Friday, 13 January 2006 10:25 AM
> To: freebsd-questions at
> Subject: Remote backups, reading from and writing to the same file
> Hi list,
> For a while I have been doing remote backups from my little server at
> (which hosts some personal websites and also serves as my testing 
> webserver) by tarring everything I wanted to be backed up and piping
it to 
> another machine on my network with nc(1), for example:
> On the recieving machine: nc -l 10000 > backup-`date +%Y-%m-%d`.tar.gz
> On my server: tar -c -z --exclude /mnt* -f - / | nc -w 5 -o aphax
> (Some excludes for tar(1) are left out for simplicity's sake)
> Among the things being backed up are my mysql database tables. This
> me wonder wether the backup could possibly get borked when mysql
writes to 
> any of the mysql tables while tar is reading from them.
> Do I really have to use MySQL's tools to do a proper SQL dump or stop 
> MySQL (and any other services that may write to files included in my 
> backup) before doing a backup? Do any of the more involved
> solutions have ways of working around this? Or is it simply not
> to write to a file while it is being read?

hi hans,

just some points to note in a general unix / db way ( not freebsd or
mysql specific ) :

tar ( and unix in general ) doesn't care if you're writing while you're
reading, so the tar will 'work' - though I believe tar may get confused
if you create new files while tar is running. 

just copying a 'live' db file will generally not give you a recoverable
backup. e.g. with 'oracle' you need to put files into backup mode before
copying them which lets oracle maintain extra recovery information. with
'ingres' you use the ingres backup command which records before images
along with the database files ( and incidentally prevents table creation
( i.e. new files ) while it backs up the db - usually with tar! ). so
you really need to find out what 'hot' backup is supported by your db
and run accordingly. or just shut down your db's before running your
backups. a common way to manage database backups ( if you have the space
) is to use normal db backup methods to backup to local disk, then use
the remote backup to backup the db backup ( and exclude the live db
files since they're probably not usable anyway ).

the number one rule for ALL backup regimes is - TEST YOUR RECOVERY
METHOD - preferably regularly. a real recovery is not the time to find
out what the shortcomings in your backup methodology are.


More information about the freebsd-questions mailing list