Re: [PLUG] Solaris backup/restore

[bergman@merctech.com]

In the message dated: Wed, 06 Feb 2013 13:43:07 -0500,
The pithy ruminations from Rich Freeman on 
<Re: [PLUG] Solaris backup/restore> were:
=> On Wed, Feb 6, 2013 at 1:18 PM, Sean M. Collins <sean@coreitpro.com> wrote:
=> > On Wed, Feb 06, 2013 at 12:14:49PM -0500, Eric Lucas wrote:
=> >> They suggested using dd and scripting it but I know the disks (200
=> >> GB) are not full so using dd seems like a crazy waste of space (DVDs full
=> >> of nothing.)
=> >
=> > I think you can just pipe dd through gzip when you're creating the backup - it'll
=> > compress the unused space. Then just pipe gunzip to dd to restore.
=> 
=> I think (but could be mistaken) that they essentially want to do the
=> restore while doing the backup - that is their backup is a clone of
=> the original drive, which means you could just swap the drive out and
=> power up and be running.

"...just swap the drive..." :)

It's been a while since I've used Solaris, but the fond (and not so nice)
memories remain.

Running Solaris a machine with 2 drives and periodically mirroring them, with
the intent of swapping the boot drive for the "backup" in case of a failure
sounds like a good idea, but it's really not that simple in practice.
Mirroring with higher-level tools (rsync, unison, etc.) is likely to cause
issues when it comes time to use the "backup".

Do a quick search for:

	/etc/path_to_inst
	devfsadm
	drvconfig
	boot -r (from the "Ok" prompt)

for some info about what may be involved in booting from the 'mirror' disk.
	

Mirroring the boot drive via "dd" has a reasonably high chance of success,
and will provide an accurate, bit-level copy of any corrupted data. If
both the boot & mirror drive are permanently installed in the same server,
then they are both subject to the same events (power surge, water, fire,
etc.) that would require the use of a backup. In my book, a single image
copy is not a reliable "backup" scheme.

Mark

=> 
=> In that case gzip won't buy you anything - every cluster on the source
=> drive has to read, and every cluster on the destination drive has to
=> be written.  Those are the rate-limiting steps so anything you do on
=> the CPU in-between won't do much.
=> 
=> If you were storing the image files then compressing them would
=> obviously reduce space use, and if you could store a compressed image
=> instead of a live image then it would also reduce the number of blocks
=> to be written during the backup.
=> 
=> Rich
=> ___________________________________________________________________________
=> Philadelphia Linux Users Group         --        http://www.phillylinux.org
=> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
=> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
=> 

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug