Can a script be triggered by an rsync backup?

[morganw]

I'm looking to backup a Moodle installation running on one virtual server, and a Joomla installation on another. I've tested rsync to pull the data from one, then the other onto a physical backup server which works with no problems but ideally I don't want to have the MySQL databases pre-dumped in order to back them as they won't be in sync with the data. Is it possible to launch a trigger a script by initiating an rsync connection or would I have to make use some kind of remote execution script that would do all the prep work beforehand, then initiate the rsync connection. I want to keep it as simple as possible though so somehow getting the rsync daemon to dump the database seems the ideal way to do. It seems logical to me that something like rsync would have a pre and post transfer command option.

[morganw]

...just found them I think.

 

pre-xfer exec and post-xfer exec.

 

Amazing what you learn by reading the instructions. :-)

[featured_spectre]

they are the correct commands, i did it at another school and it works fine, but make sure that before you do it, take a full backup of your database just in case, i saw in our first try, every table got dropped and all data along with, we had to restore it and go through it 1 step at a time.

[morganw]

Do you mean that the first time you tried to use msqldump through a pre-xfer exec script that it dropped the tables for no reason?

[featured_spectre]

yeah. you have to be careful and make sure you do not rush it. what we did was mis-coded the exec script, but for safety sake i made a backup before i started, something i do out of habbit.

[morganw]

Any idea why I can't stop Apache and MySQL from pre-xfer exec, but I can start them? The rsync daemon is running as root so I thought it would work. I've tried through inetd and running it directly from the console.

[powdarrmonkey]

The simplest way to achieve this would be with a cron-called script. On Debian/Ubuntu systems:

 

set -e
invoke-rc.d apache2 stop
invoke-rc.d mysqld stop

invoke-rc.d mysqld start
invoke-rc.d apache2 stop

[morganw]

I'm looking to pull from the servers to a backup server, rather than push onto a backup server so the backups are queued and don't overload the SAN (all servers except one are virtual). I'm thinking about backing up things like Moodle, I can dump the database in pre-xfer exec so it's up-to-date, but I wanted to stop the web services and so that someone couldn't be using it and modifying things while the file backup is running (as the the database would then be out of sync with the data). Or should I not worry about that happening?

[morganw]

Out if interest, was does 'set -e' do?

And what does invoke-rc.d do that is different from using /etc/init.d/apache2 stop

I'm am using Debian (Lenny).

[powdarrmonkey]

Out if interest, was does 'set -e' do?

 

Causes bash to halt if it encounters an error with any of the commands.

 

And what does invoke-rc.d do that is different from using /etc/init.d/apache2 stop

 

From the manual:

 

invoke-rc.d is a generic interface to execute System V style init

script /etc/init.d/name actions, obeying runlevel constraints as well

as any local policies set by the system administrator.

 

I'm am using Debian (Lenny).

 

An excellent choice

 

 

I'm looking to pull from the servers to a backup server, rather than push onto a backup server so the backups are queued and don't overload the SAN (all servers except one are virtual). I'm thinking about backing up things like Moodle, I can dump the database in pre-xfer exec so it's up-to-date, but I wanted to stop the web services and so that someone couldn't be using it and modifying things while the file backup is running (as the the database would then be out of sync with the data). Or should I not worry about that happening?

 

Well if you really want to co-ordinate this centrally you have three options as I see it:

 

a) use ssh on the backup server to log in to each server in turn for the service commands, and do your rsync from there;

b) use ssh on the backup server to run a local script on each server in turn, which pushes the backup to the server;

c) space out the backups overnight, so each server gets a chance at running full pelt (every other hour, for example).

[morganw]

I would go for a) but I also need to backup windows servers and don't want to install anything like cygwin.

Are there no permissions I could modify to allow the rsync daemon to stop apache? I guess I can automate a VM snapsnot as well to try and get a more complete backup if it can't be done.

[mac_shinobi]

...just found them I think.

 

pre-xfer exec and post-xfer exec.

 

Amazing what you learn by reading the instructions. :-)

 

LOL - was wondering why they called it RTFM aka read the fine manual ( polite version )

[mac_shinobi]

I would go for a) but I also need to backup windows servers and don't want to install anything like cygwin.

Are there no permissions I could modify to allow the rsync daemon to stop apache? I guess I can automate a VM snapsnot as well to try and get a more complete backup if it can't be done.

 

Not really familiar with *nix yet but curious is there something equivalent to WMI where you could monitor for a specific process ending or finishing and then once it finishes to do something else prior to or afterwards ?

[powdarrmonkey]

I guess if you really want an absolute snapshot of the state of the machine, that's what you have to do... I don't think you need to be so precise though, why don't you have pre-xfer do a mysqldump? It won't take long, and in the middle of the night the chances of something being uploaded that the database doesn't know about are minute.

[morganw]

I guess if you really want an absolute snapshot of the state of the machine, that's what you have to do... I don't think you need to be so precise though, why don't you have pre-xfer do a mysqldump? It won't take long, and in the middle of the night the chances of something being uploaded that the database doesn't know about are minute.

 

I guess the worst I could end up with would be files uploaded into Moodle that the database doesn't know about so they would be orphaned if I had to do a restore, but as you say the chances of it happening are minimal. I've found it pays to be paranoid though, the SAN is running RAID6 for my peace of mind but i'm trying to get a backup strategy that is the best it can be in the unlikely event that it suddenly bursts into flames.

 

Thank you for the advice by the way and info by the way. Always keen to do more through linux and similar.