Re: Rsync
- From: Joe Beanfish <joe@xxxxxxxxxx>
- Date: Thu, 24 Jul 2008 14:26:02 -0400
Unruh wrote:
Joe Beanfish <joe@xxxxxxxxxx> writes:
Unruh wrote:Mtek <mtek@xxxxxxxxxxx> writes:
On Jul 23, 6:54=A0am, Frank Elsner <Frank.Els...@xxxxxxxxxxxxx> wrote:I do not use database tables, so do not know what problem it is thatUnruh wrote:gMtek <m...@xxxxxxxxxxx> writes:Hi,
I have 2 servers. =A0One is a web/mail server and the other is a backup
server. =A0Currently, to back up the server I have a script that runs
which basically tar's the entire apache tree along with dumps of the
MySQL databases and use SCP to send them to the backup server.
Later, a script runs on the backup server which untar's the files and
imports the databases.
My question is, is this a good backup method? =A0I see many people usin=
??OK but cumbersome.RSYNC. =A0Would this be a better solution? =A0If yes, how would I do it=heYes, it would be. rsync also checks the data for correctness ( hashes t=Well, are you also saying that I do not need to export and re-importsame) while transfering it.What about database file with holes, postgres comes to my mind.
It also transfers only what has changed, not everything every time.
Is it save to rsync them?
--Frank- Hide quoted text -
- Show quoted text -
the database tables? That it will copy the databse files and mySQL
will work fine on the backup server?
you are describing. HOwever what rsync does is to make an exact, bit for
bit copy of the files, including all of the times associated with the files.
It then uses a checksum (md4) to make sure that the
two files are identical. I assume that identical files are treated by mySQL
in an identical manner. If mySQL somehow mushes together the CPU serial
number, the hard disk size, the network MAC address in determining how it
treats a file, then all bets are off. But I can see no reason why it
should.
The problem is that the database may change while the rsync is in
progress such that the copy is not only old, but corrupt. To ensure
a good copy the database must be inactive or locked for the duration
of the copy. The dump takes care of that. rsync doesn't.
But rsync will tell you that it could not do the transfer because the file
had changed. As I said, rsync does a md4 hash of both and makes sure they
are the same after the transfer. If the file has changed they will not be
the same.
Telling is great. But in the end the necessary result of a backup did
not occur.
Yes, you should switch OFF any file changing while the transfer is going
on. That is true for ALL backup options. Ie, while backing up do notallow
the database to be updated. rsync at least lets you know that has happened.
(Note that there must be enough space on the target to hold an extra copy
of the largest file to be transfered as rsync makes copies to preserve the
old file until the new one has been checked to make sure it is valid).
Note that you can run rsync say 3 times in a row to catch any files which
were active on the first run. This will not cost anything as the good files
will not get transfered again, just the changed ones.
Multiple tries could be a good strategy for low to moderately active
databases. But those in continuous flux it'll never get it right unless
there's a tool to allow locking of the entire database for the duration
of the rsync process.
Also note that rsyncing nothing isn't free. There's still the time and
disk bandwidth used to find and checksum the desired files. We've found
that on filesystems with many many files the time it takes for rsync
to even start copying anything is very substantial.
.
- Follow-Ups:
- Re: Rsync
- From: Unruh
- Re: Rsync
- References:
- Prev by Date: Re: SSHD: Limit login attempt rate
- Next by Date: Re: Limit login attempt rate
- Previous by thread: Re: Rsync
- Next by thread: Re: Rsync
- Index(es):
Relevant Pages
|
