[Rear-users] Hi to the ReaR community

Dag Wieers 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:

PRIMARY_POST_START_SCRIPT="
     command1;
     command2;
"

PRE_STOP_SCRIPT="
     command1;
     command2;
"

POST_TAKEOVER_SCRIPT="
     command1;
     command2;
"

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
        echo
    fi

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 
verbose.


> -          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 
single tape.

But if you share your requirements and ideal workflow, you might make me 
reconsider ;-)

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 mailing list