backup plan bare metal
Rodney Richison
Mainly for servers.
Tar?
Easy/quick way to restore bare metal?
Rsync? Can it do bare metal? what about hard links?
Again, easy/quick way to restoe entire debian server?
Unfortunatly, I've found mondo unreliable for bare metal. Though when it
works, it's the cat's meow..
--
Highest Regards,
Rodney Richison
RCR Computing
http://www.rcrnet.net
118 N. Broadway
Cleveland, OK 74020
918-358-1111
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Koski
> Would be interested in seeing what some of you use for a backup plan.
> Mainly for servers.
> Tar?
> Easy/quick way to restore bare metal?
>
> Rsync? Can it do bare metal? what about hard links?
> Again, easy/quick way to restoe entire debian server?
>
> Unfortunatly, I've found mondo unreliable for bare metal. Though when it
> works, it's the cat's meow..
The last time I checked mondo looked like a dead project. The links were dead
on the web site as well as the mirrors I checked. I know it is not the same
but have you looked at backuppc?
David
david....@kosmosisland.com
Alvin Oga
hi ya rodney
On Tue, 20 Sep 2005, Rodney Richison wrote:
> Would be interested in seeing what some of you use for a backup plan.
backup plan ... i always run 3-5 duplicate servers at the same time ..
just change the ip# and the backup machine would be live
> Tar?
find | tar | grep -iv is all what one needs to do 8-day, 32-day, 180-day
incrementals + full weekly backups
> Easy/quick way to restore bare metal?
take a virgin disk .. plug it into any pc and have a go at it
once the initial systemis installed from cdrom or you-favorit-tool
- it can be 1 minute or 1hr or 1 day to get a working box
back to the same state as your master box
- apply all patches ( my rules, even if it makes it newer than
the original master server )
- restore your /home data onto the newly recreated machine from bare metal
> Rsync?
rsync is extremely bad idea because:
- whatever caused your main server to die will propagate
itself on your backup server when you use rsync
- rsync does NOT save a copy of the file before you overwrite it
> Can it do bare metal?
anything can do bare metal .. once you have a workign system such
that you can run "rsync"
> what about hard links?
hard links, soft linke and hanging links and anything else is
all part of the choice of different apps you use to create probalems
or avoid problems because foo-app you used cannot do the trick
> Again, easy/quick way to restoe entire debian server?
- boot a minimal deb install from fopppy or cdrom
- do net installs and upgrades
- restore your /home data and other directories *-you-* modified
> Unfortunatly, I've found mondo unreliable for bare metal. Though when it
> works, it's the cat's meow..
80% - 90% of most of the backup programs will all fail one or more fo the
backup and restore tests ... for any number of reasons ..
- you figure out what is important to you
- why did the primary server die
- do you care if the problem propagates to other servers
- do you care that the new replacement hardware is different
- do you want to fiddle with the backups daily, weekly, monthly ??
- do you need a gui to point-n-click around
- do you need to recover the data of the machine till Jul 4, 2005
before the first sign of the cracker and sleeper that you just
found a month or 3mon or a year later
- is automated backup that works by itself with 1 line in cron
or point-n-clicky backups
- how fast does your backup need to go live when the primary goes
down
- is automatic fail over a good or bad idea ??
- the carcker will rm -rf your backup too if you're nto
careful about services and passwd and vulnerabilities
- how much USER data of backup do you need
10MB, 100MB, 1TB, 10TB ...
- how do you protect against dead disks, dead fans, dead
powersupplies, dead ethernet card, ...
- how do you protect against kernel upgrades and other
required system patches and upgrades
- how much is it gonna cost ( in hourly $$$ losses ) if the
primary server dies
- how much is the backups gonna costs and where is it
- gazillion metrics
==
== all those answers will dictate which backup and (baremetal) restore you
== should be using
==
c ya
alvin
David Koski
> > Rsync?
>
> rsync is extremely bad idea because:
I think rsync is an extremely good idea for data backup.
> - whatever caused your main server to die will propagate
> itself on your backup server when you use rsync
Huh?
> - rsync does NOT save a copy of the file before you overwrite it
man rsync!
But I think the original poster is looking for something like Ghost but for
Linux. But for data backup, rsync rocks! Over a network it minimizes
bandwidth and with some scripting you can have a very resource efficient
backup system. But you may want to go all the way and use backuppc.
Marty
> Would be interested in seeing what some of you use for a backup plan.
> Mainly for servers.
> Tar?
> Easy/quick way to restore bare metal?
>
> Rsync? Can it do bare metal? what about hard links?
It's possible using a rescue floppy or knoppix.
> Again, easy/quick way to restoe entire debian server?
I use a mirror drive. Recovery is as easy as selecting a new boot
drive in the BIOS. You can replace or restore the original drive
at your leisure.
>
> Unfortunatly, I've found mondo unreliable for bare metal. Though when it
> works, it's the cat's meow..
>
I don't see much advantage. You can just mount the replacement drive in a
working system and restore it from the backup server.
David Christensen
Rodney Richison wrote:
> Would be interested in seeing what some of you use for a backup plan.
> Mainly for servers.
> Tar?
> Easy/quick way to restore bare metal?
> Rsync? Can it do bare metal? what about hard links?
> Again, easy/quick way to restoe entire debian server?
> Unfortunatly, I've found mondo unreliable for bare metal. Though when
> it works, it's the cat's meow..
Let me preface the following by stating that I have just a few personal
machines on my LAN/DMZ, and that there is no time pressure other than
inconvenience if I need to recover from a disaster.
Machines with data have cron scripts that create tarballs and MD5
checksum files (on alternate drives). A dedicated backup server has a
cron script that fetches the tarballs and MD5 checksum files using
rsync, and then checks the MD5 checksums. Disaster recovery is a
manual process of exploding the tarballs, putting everything back into
place, and/or adjusting ownership, permissions, etc..
For bare metal recovery of GNU/Linux machines, I've tried and failed
several times in the past with Norton Ghost 2003. I recently rebuilt a
vintage Intel Advanced/AS (Atlantis) and Pentium 166 MHz machine with
Debian 31r0a (minimum install, one normal user), and have been wanting
to do some more testing with Norton Ghost 2003. Tonight, I did:
1. The Symantec web site says that Ghost 2003 will do Ext2 and Ext3
file systems and the LILO boot loader:
http://service1.symantec.com/SUPPORT/ghost.nsf/docid/1999021909463125?Open&src=&
docid=2000033111503625&nsf=ghost.nsf&view=docid&dtype=&prod=&ver=&osv=&osv_lvl=
2. This is the partitioning scheme of the Debian 31r0a drive:
/dev/hda LILO in MBR
/dev/hda1 /boot using Ext2
/dev/hda2 / using Ext3
/dev/hda3 swap
3. Tonight I took two Ghost 2003 images (see A:\GHOST\GHOST.INI for
options):
a. One with the AutoName, Image Boot, defaultTape, and
locktype-none options.
b. Another with the AutoName, Image All, defaultTape, and
locktype-none options.
4. I then used a Windows 98 Second Edition startup floppy with some
DOS utilities added (esp. format) to completely change the disk:
fdisk /mbr
reboot
fdisk
enable large disk support
delete all non-DOS partitions
create primary DOS partition
use maximum size and make active
reboot
format c: /s /v:win98
(I tried the quickformat option, but wouldn't allow)
reboot and test drive -- Windows works.
6. I then restored the first image (Image Boot). Ghost indicated some
slight discrepancies in the sizes of the partitions, and I accepted
the defaults. Booting the disk, I see an "L" followed by about a
dozen lines of 99's. I guess this is LILO puking.
7. I then restored the second image (Image Disk). Ghost indicated
exact matches for the sizes of the partitions, with 1 cylinder at
the end as unpartitioned space. Booting the disk, it works!
So, Ghost 2003 can do bare metal restores onto the same drive by using
the Image Disk option. This will protect against cracking, file system
corruption, etc., and will speed up reinstalling/ reconfiguring the O/S
and any applications and data that are present in the image.
It might be possible to do a bare metal restore using the Image Boot
option if I manually tweak the partition sizes on restoration. I'm out
of time right now, but should be able to try this soon.
I would also like to run some tests to see what happens if the hard
drive crashes:
1. Restore the second image onto a different drive of the same make
and model.
2. Restore the second image onto a larger drive (most likely disaster
recovery case).
I don't have hardware available for either test right now, but might be able to
shuffle things around and try the tests in the future.
HTH,
David
R Ransbottom
> Would be interested in seeing what some of you use for a backup plan.
> Mainly for servers.
> Tar?
> Easy/quick way to restore bare metal?
Some of the replies you have gotten seem to miss the point of
"bare metal recovery"; which is to come back to your basic system
without out having to think about configuration. It presumes
that your "metal" is the same hardware configuation, more or
less per the particular recovery program. Accordingly the
satisfying ones derive the recovery system from the live
system; this puts the sysadmin in a comfortable environment.
I will recommend the Debian package "bootcd" to your attention,
this is rather like Yard but for cds or dvds, and more modern.
Summarily: bootcd lets you copy a bootable cd from your system,
it lets you exclude directories from the copy.
I have the practice of keeping a spare "rescue" root partition
on most machines. This is occasionally a great convenience.
For me this is just a Debian base install with a few extra
programs.
Grub is also to be recommended over lilo for recovery. Grub
allows a wider range of command decisions to be made at boot time.
rdev is slick but it doesn't offer redundant redundancy, so it
is more convenience than real data safety.
I use cpio to write all my backups. After you dig around to
find a 5.25 floppy drive, or some other old hardware, you do not
want to be trying to determine how to decipher some odd backup
format or look for a 8 year old version of an OS that will run
on current hardware and may run the appropriate restore program,
if you can find a copy of it.
Lastly, Preston's _Unix_Backup_&_Recovery_ seems to be the only
good treatment of the subject.
Be well,
rir