[Rear-users] Hi to the ReaR community
dag at wieers.com
Tue Jan 24 14:59:34 CET 2012
On Tue, 24 Jan 2012, Kai-Olaf Pieth wrote:
> I introduced myself to Schlomo via phone today. Until now we developed
> our own Backup-Scripts for tar/rsync to meet our and our customer
> requirements. I accidently came to ReaR while browsing through a job
> portal site :) ReaR is exactly what I was looking for. Open Source,
> customizable and understandable.
Great ! So did Rear eventually got you the job ? :-)
> 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.
> - Customizable E-Mail Notification
What kind of events would notify by email ? In my setups we use Rear from
cron automatically and in case there's a problem cron takes care of
escalating through mail. That's why we made sure Rear by default is not
> - Incremental Rsync: backup support for incremental rotating directorys. The "current" directory will be used for disaster recovery.
Schlomo convinced me that Rear is not a backup tool, and that's why I am
using rbme for doing backups separately. Since backup is much more
complex, might be scheduled and initiated centrally, is often managed by a
dedicated team, etc... I am not sure whether this is something we would
want to pursue.
I don't mind if this support is added, but I am concerned that such an
implementation will never satisfy a majority of users and is sensitive to
lots of different use-cases and myriads of feature-requests. And Rear has
plenty of use-cases already that are hard to test on a regular basis :-)
> - Logfile "database": ReaR recover for single files/folders with support for listing file/folder versions that are available for recovery. This should be possible when tar and/or rsync logfiles are saved for a while so they are available for parsing.
Isn't that part of the backup-software ? I think this fits into the
category "Rear is not a backup tool" ;-)
> - 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
But if you share your requirements and ideal workflow, you might make me
Welcome to the club !
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
More information about the rear-users