[Rear-users] Questions on handling

[Werner Flamme]

Schlomo Schapiro   [25.04.2008 17:27]:
> Hi Werner,
> 
> I will try to sort your questions:

Thanks :-)

> 
> 1. Difference between EXTERNAL & REQUESTRESTORE
> 
> EXTERNAL requires you to supply scripts for *backup* and *restore* to 
> ReaR and ReaR will call them for you
> 
> REQUESTRESTORE will not do anything for backup but halt the disaster 
> recovery process after formatting and mounting the filesystems and give 
> you a chance to restore the data yourself - that is the magic. After you 
> restore the data ReaR will then continue to deal with boot loaders etc.

OK, so far I understand. So I will supply scripts and use EXTERNAL.

> 
> 2. Manual restore not significantly slower than automated
> 
> The purpose of ReaR is to
> 1) assist Linux-unskilled admins to recover Linux systems (your vacation 
> replacement, for example)
> 2) to assist in restoring *lots* of systems, e.g. if your data center is 
> gone and you need to restore all systems into a new data center.
> 
> For all other purposes a skilled Linux admin does not really need ReaR 
> to restore a system from backup.

Case 1 is given here. Our policy requires that a server can be restored
from cold iron by nearly any other member of the department, whether he
knows the system or not. That's why I tend to have a foolproof method.
ReaR seems to be the right way.

> 3. RSYNC_SSH outside script
> 
> This is a question about bash and variable scope. Bottom line is that 
> something you set in a bash script stays local to that script as a local 
> variable. If you want to set this globally, use /root/.bashrc (for root 
> only) or /etc/profile (or /etc/profile.d/rsync.sh or something like 
> that). BTW, this is not a ReaR related question ...

Sure, I know this. It is a RBME related question, since this occurs when
invoking RBME (at first, manually) as you suggested in your last mail. I
do not need RSYNC_SSH outside RBME; /etc/rbme.conf sets a value,
/usr/bin/rbme sources /etc/rbme.conf - but shows another value then.
That's puzzling for me since setting values in one file and sourcing it
into a shell script is done quite often on my boxen.

> 4. I am looking for customers to sponsor more backup software 
> integration, so maybe your place might be interested in having NetBackup 
> implemented ?

Before I am allowed to spend any money on open source software, I am
requested to use whatever is provided by Sun. :-( :-(

> Schlomo
> 
> PS: I do not follow you about a VM not beeing accessible ... ?

To try to reproduce the demo on a local system I need a VM. On my PC is
no space left on device :-(, my servers are forbidden to use for
testing... No, I do not comment on Public Sector in Germany now ;-)

> PPS: I have a feeling that you are trying to do something very complex 
> for a very simple problem.

So think I. I have to provide a foolproof solution, that must be tested
- but I am not allowed to use appropriate resources, and that makes it
hard to evaluate... :-(

Best regards,
Werner


> 
> Werner Flamme wrote:
>> Schlomo Schapiro   [23.04.2008 20:55]:
>>> Hi Werner,
>>>
>>> well, the documentation is somewhat lacking still, though I hoped that the 
>>> general part would be sufficient to cover your question (feel free to submit 
>>> better documentation :-))
>> Hi Schlomo,
>>
>> I'd like to, given the case that I understand what I do :-)
>>
>>> Implementing support for another backup solution is fairly simple, took me 2-3 
>>> days each time.
>> The only client installed on the hosts is a Java client, and I do not
>> want to automate the restore here ;-) The time I need for restoring
>> manually compared to automated restore is - nearly the same...
>>
>>> The backup methods REQUESTRESTORE and EXTERNAL are special because they don't 
>>> take anything into the rescue system but expect some "magic" to restore the data 
>>> when requested or allow specifying your own custom scripts. But it is always 
>>> better to write a support module for your backup software because that would 
>>> allow you to fully utilize the power of rear and also contribute your effort 
>>> back to the project.
>> For EXTERNAL, I saw this from /etc/rbme.conf, but what kind of magic
>> does REQUESTRESTORE expect? EXTERNAL allows to include user-written
>> scripts doing the work, initiated by rear (that is really great!), and
>> REQUESTRESTORE just says "Restore now!" and it's work is done, right? ;-)
>>
>>> One popular example for REQUESTRESTORE is having the backup done with rsync 
>>> (e.g. RBME) and then obviously the backup server has to push the data back to 
>>> the system (using rsync over ssh). If you are looking for a simple backup 
>>> solution besides NetBackup, do take a look at RBME as it simplifies the rsync 
>>> backup.
>> At the moment, I do not know why my parameters vanish...
>>
>> In /etc/rbme.conf I have (amongst others)
>> RSYNC_SSH="ssh -i /root/.ssh/rbme-rz36-key"
>>
>> In /usr/bin/rbme, I changed (~ line 110):
>> test -s "/etc/$ME.conf" && . "/etc/$ME.conf" && echo "/etc/$ME.conf
>> gelesen" > /root/rbme.log
>> env | grep -i rsync >> /root/rbme.log
>>
>> In /root/rbme.log I see:
>> /etc/rbme.conf gelesen
>> RSYNC_RSH=ssh
>>
>> Outside the script, RSYNC_RSH is unset.
>>
>>> Regards,
>>> Schlomo
>>>
>>> PS: If you want to quickly test the workings of rear, simply use
>>> BACKUP=NETFS
>>> NETFS_URL=nfs://host/share/path
>>> and make sure your system can NFS mount that url. The SLAC demo was just the 
>>> same, the demo film on the website also shows this in detail.
>> Hm... At present, I do not have a system that is small enough to fit
>> into any of the NFS shares avalable to me :-( And virtual machines are
>> hardly accessible either, but with the EXTERNAL option I may gain a lot
>> - just a script that creates tarballs for the relevant directory trees,
>> puts them to a certain place and copies them away via rsync. To get them
>> back, same thing, other direction ;-)
>>
>> I'm just feeling depressed because the SLAC demo was so nice, and my
>> tries aren't... ReaR can do it, but I can't :-(
>>
>> Regards,
>> Werner
>>


-- 
Werner Flamme, Abt. WKDV
Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig
Tel.: (0341) 235-1921 - Fax (0341) 235-451921
http://www.ufz.de - eMail: werner.flamme at ufz.de