[clug] Hoary old chestnut: Use of 'dump'

[Stephen Granger]

Thanks for your warning in regards to the timing condition with rsync
Antti. I guess I should have assumed the same problem could plague
rsync... I guess it's just my bias towards rsync and unfamiliarity with
dump/restore. I've only really got a linux background, very little unix
experience (des that make any sense?).

Rather than the back "everything" up scenario, I like, and have seen in
practice, and am more favourable to, back up as little as possible up
and build your servers in a common way. Use packages as much as
possible, even if you have to build them yourself (eg php on debian
which doesn't have --pspell). This process can be very handy if you are
creating/replicating servers with 'simple' services, such as webservers
(okay, may not be simple). To add, even if you can't build your servers
in a generic way utilise such tools as FAI (Debian) and Kickstart
(Redhat) so that you can replicate your base/total system as easily as
possible. This avoids backing up alot of the /usr filesystem .Store
configuration files in a central repository so you and the other
sysadmins can edit them and you are aware of the changes (CVS).
Following the Linux Files System Hierarchy (FHS) allows you to be aware
what files are where that need to be backed up.

The main resistance I've come across to this proposal is:
"What about the other files on the system that you don't know about?
you'll miss them if you don't backup everything!"
(Again, this maybe very linux centric)
You mean you've got files all over your system that you don't know
about? This maybe the case if you didn't build the box, but if you built
the box, shouldn't you know what's on it? tripwire can be your friend to
tell you what files are modified/created.

If you didn't build the box you should aleast know how to build the box
from scratch, document that process so you know how it's built and then
do a diff (again, I love rsync for this, but there is probably a better
way to do it) on the box you've just built and the other one you didn't
build. You'll have to wade through (grep out maybe) all of the log files
you know about and other stuff (content, databases, etc) but it may just
dig up the file named
Do_not_delete_runs_everything.sh in
/usr/local/test/monday/back_from_holidays/last_nightsbackup/restore/puppydogs/two_more_sleeps/
directory which you didn't know about. (This can also help you
understand why they got rid of their last sysadmin :) )
This is assuming you have the time and adequete hardware to carry out
such an opperation.

There is a few more things that you have to be aware of, maybe I can
talk about them on Thursday night? I don't have slides or anything but I
have been working on a paper/howto/document for this process that I can
bring along.

I'd really like some feedback on my ideas, especially if you think they
are totally flawed or could do with some improvements.

Randall Crook wrote:
> --
> 
> Maybe I am a little out of it, but I usually use vdump (Tru64 with advfs)
> to disk then tar the dumps to tape (yes I still prefer tape. :)) on
> nightly cold backups (applications shutdown). Then once each 6 month
> actually do a standalone backup (single user mode).
> 
> Now this works fine for me as I am dealing with 6 syncronised application
> servers and losing one for a couple of hours each night is not a major
> problem.
> 
> This does however ensure I have a clean backup of the important data
> files. It also allows me to do standalone backups of one server as a
> reference each time I need to perform major upgrades/patches so recovery
> after a stuff up is relatively straight forward.
> 
> I have always wondered if the method i use is appropriate or the most
> efficient (cost as well as reasouces) for the environment.
> 
> As each server is almost identical to the others (hostname, ip and a few
> minor configs the only diffs between them) I usually just image a rebuild
> off an existing server, so the backups to tape are really for absolute
> desastar conditions and for the warm fuzzy feeling factor.

I guess it's not that easy to replicate your server if say all or your
servers are "disabled" (The good old biblical flood scenario). This
replication can be done just as easily with FAI or kickstart which can
be stored on a CD and given out to serveral employees, sent to a remote
location.

> If anyone can point me to better (at no extra cost) solutions, I would be
> very happy give them.:)
> 


-- 
Stephen Granger