[clue-tech] [Fwd: [clue-admin] Advice admin newb on doing a System backup]

[mike havlicek]

To be more specific, rsync your data to a remote
array, then then dump this data from the array to
tape.
This can become problematic. The concept increaseses
your backup time efficiency but in a heterogenous
environment can lead to problems eluded to before.

It seems that Sun Microsysystems fixed this problem in
June 2006. The example that I am eluding to is the bit
layout of UFS. Speaking of Sun, the bits are "flipped"
betweem x86 and ultra 64 UFS filesystems.

It is no problem unless you are doing bare metal
restore. It is not isolated to Sun. At least Sun
recognizes the problem and are working on it with ZFS.


I agree with one of the earlier posters that "a backup
is only as good as the restore". I have argued this
for years. You can backup until the cows come home.
But if you can't restore ... you are still shit out of
luck.

It might seem reversed but you do have to look at the
restore plan before you design the backup.

The internal dump and restore work fine for me under
RedHat linux. I also use the same techniques with
Solaris 9 & 10. 

Again one does have to be careful with the "bit
flipping" which is actually an endian problem. 

I have found that when I directly connect the tape
drive and dump I can restore bare metal. Both with
linux and Solaris.

I have heard nonsense like the existense of a global
filesystem that works for all unix. I think that is
bullshit, but if it exists I am very interested.

I haven't gotten answers from SAN manufactures, but I
think they run into the same problem. Only one
controlling node defines the filesysystems on shared
disk space.If your kernel "understands" read and write
on many filesystems then it will work. 


But as far as I know it doesn't.

-Mike

--- Michael Benavides <mikeb at wispertel.net> wrote:

> David L. Anselmi wrote:
> > Dave W. wrote:
> >>
> >> Hello,
> >>  I want to learn how to make a system recovery
> disk(s) for my 
> >> company's dev. server.  This is what I've figured
> so far as a plan.
> >
> > The usual advice is to figure out your recovery
> procedure first.  Then 
> > design your backup process.  (Then implement, then
> test.)
> >
> >> For the initial compression: boot the server via
> a liveCD with tools 
> >> I need.
> >>
> >> Tar/compress root to a temporary folder then if
> >4.4GB span the file 
> >> over multiple disks (not sure how to do that, but
> I got idea's)
> >>
> >> Using some sort of tool I don't know of yet (but
> I am sure exists), 
> >> make differential saves of / and /boot every
> sunday via a cron script.
> >
> > My advice is: don't even think about writing your
> own scripts.  Use 
> > rdiff-backup or bacula (for more than one
> machine).
> >
> > So.  Recovery procedure from bare metal (doesn't
> address file recovery 
> > or archiving or off-site storage):
> >
> > Buy new hardware as needed (~1 week).
> >
> > Boot off live CD of choice.
> >
> > Partition as needed (RAID, disk, LVM, ext3 for
> hardware RAID or disk, 
> > RAID, LVM, ext3 for software RAID).  Mount
> partitions to match running 
> > config under /mnt.
> >
> > Restore with rdiff-backup.  Restore MBRs with dd.
> >
> > Reboot.
> >
> > Then, backup procedure:
> >
> > Get an extra (external) disk (500GB or at least
> enough larger than the 
> > data on the server).
> >
> > Nightly backups with rdiff-backup from cron. 
> Nightly saves of MBRs 
> > with dd from cron.  Tune rdiff-backup to keep an
> appropriate amount of 
> > history.  All backup stuff goes on the extra
> drive.
> >
> > Document everything you have to do to make backups
> work.  Document 
> > everything you have to do to restore.  Now test
> and adjust process and 
> > documents as necessary.
> >
> > Write an SLA and let your developers know what a
> good SA you are.  
> > Enjoy a pop-tart in a commie-free world.  (Don't
> forget to add in the 
> > pieces I skipped like your utility partition
> (which you may be able to 
> > rebuild from the install media)).
> >
> > While recreating the partitions by hand might seem
> clumsy, it's easy 
> > if you have all the steps written down.  And
> that's the piece you 
> > don't do very often.  And you want the nightly
> piece to be simple and 
> > reliable.
> >
> > Does that help?
> >
> > Dave
> > _______________________________________________
> Does this sound like a good Monthly topic for  the
> Group?  Data backup 
> is  coming out of the basement and we really have to
> recover that data 
> we put on tape. .... ... .. . ..  Linux Backups made
> Easy by Dave.... 
> Sounds like a book there? 
> 
> Mike
> _______________________________________________
> clue-tech mailing list
> clue-tech at cluedenver.org
> http://www.cluedenver.org/mailman/listinfo/clue-tech
> 




 
____________________________________________________________________________________
Sponsored Link

Mortgage rates near 39yr lows. $420k for $1,399/mo. 
Calculate new payment!
http://www.LowerMyBills.com/lre