home Mail List
Info
Info
Meetings
Goals
Upcoming
Projects
FAQ
Security
Links

[Date Prev][Date Next] [Chronological] [Thread] [Top]

[NMLUG] Disk-to-disk copying and booting



The problem may actually be duplicate device "labels", rather than
duplicate partitions.  If your /etc/fstab uses "LABEL=" syntax in the
first column, try changing those to actual device names, i.e.,
/dev/sda1, etc.  

-Ed


On Mon, 2004-09-20 at 09:32, Matthew McCleary wrote:
> Hello,
> 
> I am trying to implement a disk-to-disk backup scheme on a server.
> It's not the ideal method (I would have chosen a tape backup myself),
> but it's what I have to deal with.
> 
> I've got three 146 GB ultra-320 SCSI disks. They are installed in a
> removable drive frame, though I do not think they are hot-swappable;
> thus, when I install or remove one, I have to first take the machine
> down.
> 
> One drive has a complete Red Hat 9.0 system installed on it, which is
> essentially one large partition minus a small /boot partition and a 2
> GB swap partition. The disk is designated /dev/sda.
> 
> I've been using dd if=/dev/sda of=/dev/sdb bs=1024k (and dd
> if=/dev/sda of=/dev/sdc bs=1024k) to make a carbon-copy of sda onto
> sdb (or sdc). I'm supposed to do a periodic backup of sda -- something
> like once a month, rotating the two backup drives monthly. Thus we
> would lose at most a month's worth of work, worst-case.
> 
> Here, I come to the problem. To make a new backup, I just run the "dd"
> command again -- it doesn't care what's on the drive currently, and it
> will even overwrite the partition map. Quite nice. The problem,
> though, happens when next month rolls around and I want to make a new
> backup.
> 
> If I take the server down and install one of the backup drives in the
> frame, alongside the main drive, and boot it up, Linux freaks. It sees
> duplicate /boot partitions (and actually, it would see duplicates of
> all filesystems) and refuses to mount anything it sees a duplicate of.
> I *think* it actually boots, but it does not mount all filesystems,
> which of course will cause problems.
> 
> The only way I can think to get around it is to first delete the
> entire partition map on the backup drive (essentially, destroy the
> backup) and then install the blank backup disk in the frame, and then
> boot. That seems to be the only way I can get Linux to boot normally.
> 
> Problem is, I don't have another server that I can install these
> drives into -- and so the only way I can destroy the partition map is
> by installing the drives in the very server I'm trying to back up -- a
> "chicken and the egg" problem.
> 
> So, I'm appealing to you: what advice would you have for me to go
> about solving this problem? A tape backup is (unfortunately) not an
> option; due to policy I must do disk-to-disk backups.
> 
> Thanks,
> Matthew




Please send sugestions and comments to webmaster@nmlug.org.
Valid XHTML 1.1! Valid CSS! Powered by Debian Powered by Apache