Re: [adr-devel] Amanda Disaster Recovery Scripts.

[Stefan Gregor Weichinger]

Hello, Alex, you wrote:

AO> (PS: is any one on this list interested in taking this idea forward?)

Yes ;-)

At first let me say that I am happy about the fact that this list
isn't as plain dead as I thought.

Nice work so far.

AO> Use OS features to make a snapshot of filesystems

I do such snapshots via shell-script (find/tar).
Is this feature available for Linux or is it Solaris-specific?

AO> I also have a cron job that runs at say 10 to midnight which collects
AO> important metadata ie partition layout etc and save this under
AO> /etc/diskinfo/

Selfmade script?

AO> I net-boot the failed server from the Amanda server and restore from tape
AO> directly onto disk. There is a sun "blueprint" which shows you how to
AO> modify a Solaris installation netboot image to be a generic readonly NFS
AO> root image. I have also adapted this idea for Debian/Linux.

Could you provide more details on this?
I would love to be able to generate such an image every month or so,
automated, if possible.

AO> So I netboot the faild server into the disaster recovery environment which
AO> has the normal amada tools and any custome ones (ie ADR) and then I can
AO> amrestore some metadata from the root partition backup on tape to
AO> /tmp/etc/diskinfo and /tmp/etc/fstab.  I can then use this meta-info
AO> manually (or in future automatically) to repartition the dirves.

AO> Guided by the meta info I have already restored I can then communicate
AO> with the amada server via rsh to do:
AO> "amadmin Daily info host ^/snapshot/<partition>$"
AO> to find the tapes to restore.

Any reason why you use rsh? Should be ssh these days ...

AO> Amanda server recovery:
AO> =======================

AO> I have done most if not all of the preceeding steps. This step I have
AO> planned but have not yet tested.

AO> My Amanda Server is a Debian Linux server. I can netboot Debian, Solaris
AO> and IRIX (miniroot) from this server. There is no reason why any unix like
AO> operating system that can boot via DHCP/bootp->tftp->NFSroot could not be
AO> persuaded to boot/run from this debian server.

Yes. Good plan ...

AO> Debian has a package bootcd which allows me to make copy of my debian
AO> server onto a bootable live CD. I can therefore boot this CD and use this
AO> to restore the latest Amanda server image from tape.

AO> The amanda database/config will be about one run out of date so I expect
AO> that we would need to "amadmin import" an "amadmin export" file. Currently
AO> I e-mail these off the amanda server at the end of the run. I guess I
AO> should append this info to the end of that days amanda tape.

There have been ways of doing this. I know of a solution to just
generate that export-file after the amdump, position the tape after
the last dump and append to it. So the tape would continue up-to-date
metadata.

I think this should go into AMANDA itself sooner or later.
This would improve the disaster-recovery-usability ...

AO> ----------------------------
AO> Here are a couple of bash functions that I am developing to help speed up
AO> the manual process... Perhaps they could grow to form the start of
AO> ADR-0.0.1 ?

Have to look at them ...

AO> do_snap_restore should be extended to take the tape and file number info
AO> found using find_snap_tape. It should then ensure the tape is loaded and
AO> "mt asf" to the correct file on tape.

AO> find_snap_tape should be changed to use "amadmin info" rather than
AO> "amadmin find" as at present!

AO> find_snap_tape(){ #fs=$1
AO>     rsh  amanda.server -l backup /usr/sbin/amadmin Daily find
AO> --sort dl   failed.server /snapshot${1}\\\$
AO> }

Shouldn't failed.server get something like $1 and fs $2 ?
...

Thanks so far for contributing, I look forward to new ADR-developing
...

Stefan