On Fri, Feb 11, 2011 at 10:38:52AM -0800, Scott Hess wrote:
On Fri, Feb 11, 2011 at 9:04 AM, Ruediger Schmitt
<ruedigerschmitt < at > ymail.com> wrote:
The "permanent" snapshot should not reflect the most recent backup, but the
newest state at the moment when the snapshot is taken.
I could run another "rsnapshot hourly" and then your copy command, but this
would change the regular backup schedule.
Does rsnapshot offer an option to execute its rsync steps into a new directory
without cycling the hourly, daily, ... snapshots?
For giggles, I'll assume that since you don't want to wait, your
tightest backup loop is happening daily. For purposes of discussion,
you see, so I don't have to worry about the problem. So if I wanted a
"now" copy, I'd probably pull out the part of the config which deals
with what-to-backup, and put that in another file which the main
rsnapshot.conf includes. Then I'd make a second config file with a
new snapshot root on the same filesystem. Then, somewhere safely
between rsnapshot runs, I'd do the cp -al to shift a replica of the
most recent backup into the second snapshot root, in the most recent
backup position for that root. THEN I'd run rsnapshot with the other
config file. Lastly I'd rename the backup to whatever I wanted (or
consider having the config line be something like "interval capture
10000000" and using ls -lt to find the time).
That sounds quite complicated to me.
I would be more inclined to change your rsnapshot config to use
sync_first 1
(if you are not already using sync_first). In short sync_first
de-couples the rsync part of rsnapshot from the rotation part of
rsnapshot.
There are one or two other things you should do if making that change,
the most important being to change your rsnapshot <lowest interval>
command in cron to rsnapshot sync and rsnapshot <lowest interval>.
See the rsnapshot man page for more details, in particular the section
CONFIGURATION (sync_first) and the USAGE (rsnapshot sync) section.
Once rsnapshot is using sync_first mode, doing an additional permanent
backup is as simple as
cd /.snapshots (or your snapshot_root)
sudo rsnapshot sync
cp -al .sync 20110211-025059
That is the same as David Cantrell's suggestion (which was the same
thing I was thinking), just with an extra sync step because Ruediger
wants to have a special one-off backup made for this purpose, rather
than copying one of the existing backups so it will be kept permanently.
Because the sync is not followed by a rotate (eg: rsnapshot daily),
this one-off sync won't be stored permanently with the other intervals,
although it could help reduce network traffic for the following sync.
If you are automating this, you should check the return code from the
rsnapshot sync. It could fail because there is already another rsnapshot
running (assuming you have a lockfile), or due to network issues, or
any of the other normal errors that could happen to rsnapshot.
A simple minded way to check the return code would be like this:
rsnapshot sync && cp -al .sync 20110211-025059
(basically the approach suggested in the rsnapshot man page).
If the sync fails for any reason, then don't do the copy.
You could be a little more sophisticated like this:
cd /.snapshots
if rsnapshot sync || rsnapshot sync || rsnapshot sync ; then
cp -al .sync 20110211-025059
else
stat=$?
echo "Error: rsnapshot sync had exit status $stat - backup failed"
exit $stat
fi
That says to try rsnapshot sync up to 3 times until (rsnapshot thinks)
it succeeds, then either do the copy or fail with an error.
Another good idea would be to put some locking code around the copy,
something like this :
echo $$ > $lockfile
cp -al .sync 20110211-025059
rm $lockfile
in case another rsnapshot starts while the cp is running.
--
___________________________________________________________________________
David Keegel <djk < at > cybersource.com.au> http://www.cyber.com.au/users/djk/
Cybersource P/L: Linux/Unix Systems Administration Consulting/Contracting
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
