Backup strategy comments requested

Tim Writer tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org
Fri Jul 2 17:29:42 UTC 2004


Alan Cohen <alan-QVObF66B6qeOg/Yh5kgvkFaTQe2KTcn/@public.gmane.org> writes:

> Hello
> 
> I'm looking for comments on a strategy I'm considering for 4 machines
> running at my home business. Each machineJ requires only 1 disk called
> "ProductionJ." GRUB is the bootloader. CLOSE to 24/7 availability is
> important.  I don't want to use RAID. (My experiences with RAID1 were
> bad and RAID is probably overkill anyway.)

I strongly disagree wrt RAID.  I've had a couple of bad experiences with
hardware RAID but I've seen far more failures of individual disks -- in fact,
I think reliability is getting worse with modern ATA disks -- and I've had
excellent results with software RAID on Linux and Solaris.  Disks are so
cheap now that I recommend all production systems be installed with software
RAID.

> In the event that ProductionJ is toast, the idea is to replace it with
> DailyJ or WeeklyJ and re-boot. That's critical. In the event of
> catastrophe, I don't want to be re-installing software.
> 
> My thoughts were to get 2 more disks for each machineJ, called "DailyJ"
> and "WeeklyJ." "Daily" would usually be installed. A nightly rsync would
> update ProductionJ's 9 partitions to DailyJ's 9 partitions.  Once a
> week, DailyJ would have to be swapped with WeeklyJ.
> 
> Is this a good idea?

With this approach, you could still lose a full day.  Start with software
RAID1 and complement it with nightly backups (using rsync or whatever) to a
spare disk as you suggested above.

> Known issues/questions:
> - Changes to the /boot partition will undoubtedly be rare.
>   How should they be made? dd?

If you mean how should you copy /boot from one disk to another (backup disk),
I would suggest a simple script that makes a file system on the backup and
copies the contents from the original using tar or cpio.  You can use dd
(from one block device to the other) as long as both devices aren't mounted
and the target partition is at least as large as the source.  If it's even a
tiny bit smaller, your backup will be toast.  I prefer the mkfs followed by
tar or cpio because it accomodates differences in size better.

>   What are the position-critical files? I'm new to GRUB: is it just
>   the "stage2" file?

I wouldn't worry about it too much.  Just make sure you have a grub boot
floppy or CD.  Grub's interactive nature makes it easy to find your kernel
(and initrd if required) even without a menu file.

> - Changes to the MBR will undoubtedly be rare.
>   How should they be made? dd?

With grub.

> - It's been suggested to use external USB devices to house DailyJ and
>   WeeklyJ, in order to accomplish a poor man's hot-swappable disk
>   scenario. (My assumption was to use "disk trays".) I have no
>   experience with USB. Would this work? Do these USB storage devices
>   contain quite ordinary looking IDE disks?

Typically, yes.  If you're concerned, you can buy the disk and USB storage
enclosure separately at a number of stores on College St.  If you go with
RAID, USB disks would be useful for your backups as you could take them off
site.  I wouldn't include them in your RAID configuration or boot from them
directly (in the event of a failure) due to performance considerations.
IIRC, USB2 is still only 154Mbps.  Also, USB can be difficult to boot from.
In my experience, many BIOSes that claim to support USB won't boot from them.
And, if the BIOS can boot from an external USB disk, you would still need an
initrd that would load the necessary USB and sd modules before mounting the
root partition.  Since USB storage emulates SCSI, your /etc/fstab would be
different when running from USB.  While all this can be done, it's a chunk of
work for marginal benefit.

Hope this helps,

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
905.771.0017 ext. 225                           thornhill, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list