server backup strategy.
The Natural Philosopher
keyboard, but missed the server) I thought its might be time to do one
of my infrequent backups..
What I have is about 4 gig of basic server stuff in / /usr /bin /var
/etc etc..
another 8 gig or so of stuff that i wouldn't like to lose.. 4 gigs of
pictures and about 4 gigs of user data..theres a lot I can cheerfully
lose, which is actually backups off other systems..
A DVD burner, and *no GUI* on a debian etch system. (access via
telnet/ssh etc only)
And some single and double layer DVDs.
So, its something like growisofs at the burn level, and provabably 3 DVDS..
some questions..
- is it better, and why, to tar up great big chunks and dump them as a
single file or to try and replicate bits of the file system? I have
forgotten how to use growisofs, but I assume if I tell it to transfer
say /home/me it will replicate the whole directory on a DVD?
- is there any reason to prefer the single layer DVDS over double?
- anything else I should be wary of? I am pondering issues of e.g.
reloading the OS onto different hardware with different disk
controllers..I guess that's not always that easy..
I might add that the purpose of the backup is disaster recovery: Assume
a dead machine or disk...and get back as much of what I want as possible
as fast as possible. i,e, I want to be able to essentially take a more
or less raw installation and roll back just about everything to recreate
working stuff... then pull the user data back onto it.
Anyway, I thought before plunging into scripting this all up, I would
ask here and see if there was anything anyone had to contribute.
Ideally a script that allows you to edit a table of areas to be backed
up onto a suite of DVDS, that prompts for new DVDS to be inserted, is
the final goal..happy to share the results if they work. Or is there one
already out there?
Ignoramus10032
Back it up remotely using rdiff-backup. Works great and is much better
than local backups. A USB drive is also an option.
i
--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/
The Natural Philosopher
> Back it up remotely using rdiff-backup. Works great and is much better
> than local backups. A USB drive is also an option.
>
Onto what machine should I back it up pray?
Ignoramus10032
> Ignoramus10032 wrote:
>> Back it up remotely using rdiff-backup. Works great and is much better
>> than local backups. A USB drive is also an option.
>>
>
> Onto what machine should I back it up pray?
>
What, you have only one machine?????
Nothing at work? Or something?
i
--
The Natural Philosopher
> On 2008-09-06, The Natural Philosopher <a@b.c> wrote:
>> Ignoramus10032 wrote:
>>> Back it up remotely using rdiff-backup. Works great and is much better
>>> than local backups. A USB drive is also an option.
>>>
>> Onto what machine should I back it up pray?
>>
>
> What, you have only one machine?????
>
Only one Linux machine..
> Nothing at work? Or something?
>
Work? Oh..that's stuff you used to have to do till you had made enough
dosh to stop doing it..
I remember work, vaguely..
Actually I have got a big old RAID DEll server but it looks like it
would cost me more per year in electricity than its worth to fire it
up..but maybe the answer is a second disk in the machine and diff to that..
Ignoramus19762
> Ignoramus10032 wrote:
>> On 2008-09-06, The Natural Philosopher <a@b.c> wrote:
>>> Ignoramus10032 wrote:
>>>> Back it up remotely using rdiff-backup. Works great and is much better
>>>> than local backups. A USB drive is also an option.
>>>>
>>> Onto what machine should I back it up pray?
>>>
>>
>> What, you have only one machine?????
>>
>
> Only one Linux machine..
You can use rdiff-backup on Windows also. You can also use shared
drives to back up.
i
>> Nothing at work? Or something?
>>
>
> Work? Oh..that's stuff you used to have to do till you had made enough
> dosh to stop doing it..
>
> I remember work, vaguely..
>
> Actually I have got a big old RAID DEll server but it looks like it
> would cost me more per year in electricity than its worth to fire it
> up..but maybe the answer is a second disk in the machine and diff to that..
>
--
Douglas Mayne
YMMV with any backup strategy. From a disaster recovery point of view, the
best alternative is to boot a live CD and work with the system being
backed up as a simple mount point. The goal is to obtain as accurate
of snapshot as desired or necessary. Testing the backup is something
which is often neglected, but it will show if your selected method has
a chance of working. Using a live CD avoids the simple glitches which
can crop up when working with file systems mounted as root. Your
requirements may preclude rebooting the computer using a live media- but
if it is subject to be hitting by vases of flowers, then I am not sure
why it is a requirement to use ssh. For my money, you can't beat the
simplicity of using a live CD. The big benefit is that standard tools and
network tools will work with catches (tar, nc, ssh, rsync).
As far as device targets for the backup, IMO, USB hard drives are best.
These have high capacities, are fairly reliable, and can be turned off
when not in use. The downside is expense, but $200/TB isn't bad. Thank you
Moore's Law ;-)
DVDs are more durable and a lot cheaper, but introduce the problem of how
to span multiple discs- i.e. how to fit a 26G backup on 4G media. For
example, I see that backup image requires about 7 DVDs:
(7 DVD x 4G/DVD = 28G cap max.)
First, I would use a live CD/USB key to obtain the backup, then reboot
into my standard distribution and post process the backup as necessary to
send it to its final destination. In the above example, I would use a
device mapper table to split the backup into exactly 4G blocks. This trick
cuts a few steps. It's not as bad as it sounds, but I'll stop right here,
to avoid going too far afield. A few more general comments follow...
I haven't used double layer DVDs because I was a bit uncertain about their
long term reliability. Also, I had enough trouble getting single layer to
work reliably.
Command Line examples:
# mkisofs -R -J -udf -o some.001.iso some_dir
(some_dir has 4G blocks of a loopback container:
/server_x/2008-09-07/2008-09-07.01.lfs.001)
# growisofs -dvd-compat -speed=x /dev/sr0=some.001.iso
(for DVD-R)
As far as other tools, I see a program called Amanda is
recommended quite often.
--
Douglas Mayne
The Natural Philosopher
Mmm. dont have a live CD..though I am sure I could make one..
Sont want to take teh system down, as it is even if at a very amatuer
scale, a public system.
> As far as device targets for the backup, IMO, USB hard drives are best.
> These have high capacities, are fairly reliable, and can be turned off
> when not in use. The downside is expense, but $200/TB isn't bad. Thank you
> Moore's Law ;-)
>
> DVDs are more durable and a lot cheaper, but introduce the problem of how
> to span multiple discs- i.e. how to fit a 26G backup on 4G media. For
> example, I see that backup image requires about 7 DVDs:
>
> (7 DVD x 4G/DVD = 28G cap max.)
Oh, splitting it up is no big deal. Thats just down to writing scripts
as the data is all in sensible sections. I dont mind doing a bit of
patching later on either..if needs be.
In fact its probably true to say that a clean install plus the various
config files for the server daemons, would get me to a system where I
could just roll data back.
>
> First, I would use a live CD/USB key to obtain the backup, then reboot
> into my standard distribution and post process the backup as necessary to
> send it to its final destination. In the above example, I would use a
> device mapper table to split the backup into exactly 4G blocks. This trick
> cuts a few steps. It's not as bad as it sounds, but I'll stop right here,
> to avoid going too far afield. A few more general comments follow...
>
Thats not needed really.
> I haven't used double layer DVDs because I was a bit uncertain about their
> long term reliability. Also, I had enough trouble getting single layer to
> work reliably.
>
MMm. that as my thought too.
> Command Line examples:
> # mkisofs -R -J -udf -o some.001.iso some_dir
>
A. I remember now. Create an iso file.. I take it of you do it that way
you end up with a mountable image full of directories etc etc.? I.e.
something that looks pretty much like what was in some_dir..and asl ong
as some_crap.iso is less than 4gigs, it will burn OK?
> (some_dir has 4G blocks of a loopback container:
> /server_x/2008-09-07/2008-09-07.01.lfs.001)
>
> # growisofs -dvd-compat -speed=x /dev/sr0=some.001.iso
>
Mmm. right.
Thanks for reminding me of the process
> (for DVD-R)
>
> As far as other tools, I see a program called Amanda is
> recommended quite often.
>
Nah. dont want no tools..only have to install them all over again..
99% of the stuff I need is either under /var. as in mysql/apache configs
and data, or under /home. as in pure samba mounted user data.
I could stop the sql daemon and samba daemons and get all that OK..
What is more an issue is recovering things like user and group files,
and server config files. MOST of that is in /etc. but I cant remember
where all the ruddy php libraries and so on reside - they were a pain to
add in, and there was some stuff that was source compiled too..
I guess that means /usr and /etc need backing up too eh?
Probably don't need / /bin /proc and so on tho..those would be replaced
at new install time.
Thanx V much...i'll have a play..