[Rear-users] Hi to the ReaR community
jeroen.hoekx at hamok.be
Tue Jan 24 15:40:47 CET 2012
On 24 January 2012 14:59, Dag Wieers <dag at wieers.com> wrote:
> On Tue, 24 Jan 2012, Kai-Olaf Pieth wrote:
>> Now I plan to use ReaR for backing up our customer's servers. I am interested in implementing some features that our own backup scripts had or that were planned for them.
>> - Customizable BEFORE_ and AFTER_ Backup commands for stopping services or whatever
> I have some ideas about this myself. We had similar requirements in the
> past for some cluster scripts to do manual failover and failback (using
> Hitachi's horcm storage tools. We ended up doing something that I
> considered the best solution for Rear too.
> The implementation looks like:
> And at various stages these code-snippets would be executed using:
> if [ "$PRIMARY_PRE_START_SCRIPT" ]; then
> echo -n $"Run primary pre script:"
> eval "$PRIMARY_PRE_START_SCRIPT" && success || failure
> In this case using Red Hat's sysv infrastructure to report success and
> failure. The benefit of using variables is that those code snippets can
> use existing Rear functionality and variables.
> This could of course also be implemented using arrays. I prefer this over
> separate scripts that are being called especially for smaller items, but
> if there's a need to have complex pre-backup and post-backup procedures,
> maybe having directories for each stage in /etc with 'sorted' scripts
> might be a better approach. I am interested to learn your requirements and
> you prefered solution.
Dag's memory is hindered by his age... Back in the day (:-)) we
proposed to add a generic hooks mechanism at various points. Our goal
back then was to reduce the number of symlinks, but their count is
pretty manageable these days.
The way it worked was similar to how you describe it.
A folder, say /etc/rear/hooks/, containing subfolders per event
(/etc/rear/hooks/post-backup) and scripts that will be run/sourced.
The patch was rejected because even customer specific scripts are
accepted into Rear (see the drbdtab script) and because the result
would have complicated Rear because we also used it internally. Rear
did have PRE_RECOVERY_SCRIPT and POST_* on the other hand...
If there is sufficient demand, the code is still around and I can see
the value in it. We would need to define when we want to emit events.
>> - Tape seeking: The tape backup option needs to write a header file at the beginning of the tape so ReaR can verify with help of the saved logfile what is on the tape and at which block number the file to restore is. Then it can seek the tape with mt to get the file very fast!
> I am interested to learn how you would use Rear with tapes for backup
> purposes and why existing tape backup software is not a better fit.
> - Do you plan to use tapes in this case as boot medium ?
> - Do you plan to store multiple archives on a single tape ?
> The reason for asking is because we spend a few months on implementing
> OBDR support, tape-archive support and workflows, and my opinion is that
> tapes make poor boot-devices, Rear is unfit to manage tape backups and
> OBDR+tape archives probably only makes sense for a single archive on a
> single tape.
I, of course, share the same opinion. We were thinking about ways to
do what you want in Rear in a manageable way, but quickly concluded
that USB sticks along with a real backup solution are far better.
Any improvements gladly accepted of course and I'd be happy to be proven wrong!
More information about the rear-users