Frank Elsner <Frank.Elsner@spamfence.net> writes:

>Unruh wrote:
>> Mtek <mtek@mtekusa.com> writes:
>>
>>
>>
>>>Hi,
>>
>>
>>>I have 2 servers. One is a web/mail server and the other is a backup
>>>server. Currently, 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? I see many people using
>>
>> OK but cumbersome.
>>
>>>RSYNC. Would this be a better solution? If yes, how would I do it??
>>
>>
>> Yes, it would be. rsync also checks the data for correctness ( hashes the
>> same) while transfering it.
>>
>> It also transfers only what has changed, not everything every time.

>What about database file with holes, postgres comes to my mind.
>Is it save to rsync them?

Yes, as far as I know. It does not blow up sparse files.
Again try it, it's cheap enough.



>--Frank

Mtek <mtek@mtekusa.com> writes:

>On Jul 23, 6:54=A0am, Frank Elsner <Frank.Els...@spamfence.net> wrote:
>> Unruh wrote:
>> > Mtek <m...@mtekusa.com> 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=
>g
>>
>> > OK but cumbersome.
>>
>> >>RSYNC. =A0Would this be a better solution? =A0If yes, how would I do it=
>??
>>
>> > Yes, it would be. rsync also checks the data for correctness ( hashes t=
>he
>> > same) while transfering it.
>>
>> > It also transfers only what has changed, not everything every time.
>>
>> What about database file with holes, postgres comes to my mind.
>> Is it save to rsync them?
>>
>> --Frank- Hide quoted text -
>>
>> - Show quoted text -

>Well, are you also saying that I do not need to export and re-import
>the database tables? That it will copy the databse files and mySQL
>will work fine on the backup server?

I do not use database tables, so do not know what problem it is that
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.


>My goal obviously is if the main server goes down, I can shut it down,
>change my router to point to the other server, and I'm up and running
>again.

>Regards,

>John.

Frank Elsner <Frank.Elsner@spamfence.net> wrote:
> What about database file with holes, postgres comes to my mind.
> Is it save to rsync them?

man rsync. Search for "sparse".

Chris

Unruh wrote:
> Mtek <mtek@mtekusa.com> writes:
>
>> On Jul 23, 6:54=A0am, Frank Elsner <Frank.Els...@spamfence.net> wrote:
>>> Unruh wrote:
>>>> Mtek <m...@mtekusa.com> 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=
>> g
>>>> OK but cumbersome.
>>>>> RSYNC. =A0Would this be a better solution? =A0If yes, how would I do it=
>> ??
>>>> Yes, it would be. rsync also checks the data for correctness ( hashes t=
>> he
>>>> same) while transfering it.
>>>> It also transfers only what has changed, not everything every time.
>>> What about database file with holes, postgres comes to my mind.
>>> Is it save to rsync them?
>>>
>>> --Frank- Hide quoted text -
>>>
>>> - Show quoted text -
>
>> Well, are you also saying that I do not need to export and re-import
>> the database tables? That it will copy the databse files and mySQL
>> will work fine on the backup server?
>
> I do not use database tables, so do not know what problem it is that
> 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.

Mtek ha scritto:

> And going along with that, you still think RSYNC is a better idea than
> ratting up specific directories and untarring them on the backup
> server?

For the simple copy of files from one server to another, it should be
better rsync because of reasons written by the other posters in this
thread. Tar is better if you want to burn backupped files on DVD.

Joe Beanfish <joe@nospam.duh> writes:

>Unruh wrote:
>> Mtek <mtek@mtekusa.com> writes:
>>
>>> On Jul 23, 6:54=A0am, Frank Elsner <Frank.Els...@spamfence.net> wrote:
>>>> Unruh wrote:
>>>>> Mtek <m...@mtekusa.com> 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=
>>> g
>>>>> OK but cumbersome.
>>>>>> RSYNC. =A0Would this be a better solution? =A0If yes, how would I do it=
>>> ??
>>>>> Yes, it would be. rsync also checks the data for correctness ( hashes t=
>>> he
>>>>> same) while transfering it.
>>>>> It also transfers only what has changed, not everything every time.
>>>> What about database file with holes, postgres comes to my mind.
>>>> Is it save to rsync them?
>>>>
>>>> --Frank- Hide quoted text -
>>>>
>>>> - Show quoted text -
>>
>>> Well, are you also saying that I do not need to export and re-import
>>> the database tables? That it will copy the databse files and mySQL
>>> will work fine on the backup server?
>>
>> I do not use database tables, so do not know what problem it is that
>> 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.

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.

Unruh wrote:

[putolin]

>
> The "easy" way
>
> rsync -av /usr/local/http/ remotehost:/usr/local/http
> rsync -av /usr/local/mysql/ remotehost:/usr/local/mysql
>
>
> which will use sshd so you would need a passwordless login on the remote
> machine.

Would it not be (to transfer with ssh) ???
rsync -ave "ssh -l ssh-user" /usr/local/http/ remotehost:/usr/local/http

From the man page:
-e, --rsh=COMMAND specify the remote shell to use

Or did I miss something?

--
Tayo'y mga Pinoy

Hello,

>
> Would it not be (to transfer with ssh) ???
> rsync -ave "ssh -l ssh-user" /usr/local/http/ remotehost:/usr/local/http
>
> From the man page:
> -e, --rsh=COMMAND specify the remote shell to use
>
> Or did I miss something?
>

The command you describe is correct. The only thing you missed is that it's
the default if you do not specify the "-e" or "--rsh" option:

From the manpage:
> -e, --rsh=COMMAND
>
> This option allows you to choose an alternative remote shell
> program to use for communication between the local and remote
> copies of rsync. Typically, rsync is configured to use ssh by
> default, but you may prefer to use rsh on a local network.
>
>

You are completely right if you want to contact a remote rsync daemon
with "rsync -av directory host::module", in that case the rsync client will
try to contact the rsync daemon directly via it's own TCP port. Now you
MUST use the --rsh=ssh option in order to use ssh for transport.


Kind Regards,
H.Janssen

Baho Utot <baho-utot@invalid.invalid> writes:

>Unruh wrote:

>[putolin]

>>
>> The "easy" way
>>
>> rsync -av /usr/local/http/ remotehost:/usr/local/http
>> rsync -av /usr/local/mysql/ remotehost:/usr/local/mysql
>>
>>
>> which will use sshd so you would need a passwordless login on the remote
>> machine.

>Would it not be (to transfer with ssh) ???
>rsync -ave "ssh -l ssh-user" /usr/local/http/ remotehost:/usr/local/http

No. All rsync these days have ssh as the default, not rsh. The days of rsh
are long long over.



>From the man page:
>-e, --rsh=COMMAND specify the remote shell to use

>Or did I miss something?

What the current default is.


>--
>Tayo'y mga Pinoy

"H.Janssen" <henny@nospam.hmmsjan.dosgg.nlnospam> writes:

>Hello,

>>
>> Would it not be (to transfer with ssh) ???
>> rsync -ave "ssh -l ssh-user" /usr/local/http/ remotehost:/usr/local/http
>>
>> From the man page:
>> -e, --rsh=COMMAND specify the remote shell to use
>>
>> Or did I miss something?
>>

>The command you describe is correct. The only thing you missed is that it's
>the default if you do not specify the "-e" or "--rsh" option:

>From the manpage:
>> -e, --rsh=COMMAND
>>
>> This option allows you to choose an alternative remote shell
>> program to use for communication between the local and remote
>> copies of rsync. Typically, rsync is configured to use ssh by
>> default, but you may prefer to use rsh on a local network.
>>
>>

>You are completely right if you want to contact a remote rsync daemon
>with "rsync -av directory host::module", in that case the rsync client will
>try to contact the rsync daemon directly via it's own TCP port. Now you
>MUST use the --rsh=ssh option in order to use ssh for transport.

Which is why I said that if you are not concerned about having the stuff
encrypted on transport, you can use the host:: form and not have the
computers spend time on encryption. Mind you this does not make much
difference unless you have a very slow machine.



>Kind Regards,
>H.Janssen