Is there a standard way of copying a working system from one machine to another with different partitions? I have two CentOS-5.6 machines, say A and B, and I thought I would copy / on sdb10 on machine A to an unused partition sda7 on machine B with rsync. I made the appropriate changes to /etc/fstab and grub.conf , as well as /etc/sysconfig/network-scripts , but found that there were innumerable errors when I booted machine B into the new system, mostly to do with creating dev's. Also the ethernet connection, which had been eth1 on A, was now eth0 on B, and this did not work. This was only a kind of experiment. There is a problem with the partition table on machine A, and I thought it would be useful to have a backup machine with exactly the same setup. Is this a hopeless enterprise, or can it be done easily? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
At Thu, 05 May 2011 12:13:18 +0100 CentOS mailing list <centos at centos.org> wrote:> > Is there a standard way of copying a working system > from one machine to another with different partitions? > > I have two CentOS-5.6 machines, say A and B, > and I thought I would copy / on sdb10 on machine A > to an unused partition sda7 on machine B with rsync. > I made the appropriate changes to /etc/fstab and grub.conf , > as well as /etc/sysconfig/network-scripts , > but found that there were innumerable errors > when I booted machine B into the new system, > mostly to do with creating dev's. > Also the ethernet connection, which had been eth1 on A, > was now eth0 on B, and this did not work.It sounds like you have problems *other* the 'copy' part. After copying the system, you will likely need to remake the initrd on the target system. Oh, you will need to edit /etc/modprobe.conf: different SATA driver, different ethernet driver, etc.> > This was only a kind of experiment. > There is a problem with the partition table on machine A, > and I thought it would be useful to have a backup machine > with exactly the same setup. > > Is this a hopeless enterprise, or can it be done easily?It is easy enough to do. There are just a few more things involved besides copying the data and diddling with grub.conf, /etc/fatab, and /etc/sysconfig/network-scripts. You just forgot about /etc/modprobe.conf and forgot to remake the the initrd.>-- Robert Heller -- 978-544-6933 / heller at deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
On 05/05/2011 07:13 AM, Timothy Murphy wrote:> Is there a standard way of copying a working system > from one machine to another with different partitions?You could also utilize cloning software, such as the client version of drbl, clonezilla livecd. You could also do a direct copy with dd onto a connected drive. You may be well served by looking into drbl, or clonezilla. -- Respectfully, Martes G Wigglesworth M. G. Wigglesworth Holdings, LLC www.mgwigglesworth.net
On 5/5/11 6:13 AM, Timothy Murphy wrote:> Is there a standard way of copying a working system > from one machine to another with different partitions? > > I have two CentOS-5.6 machines, say A and B, > and I thought I would copy / on sdb10 on machine A > to an unused partition sda7 on machine B with rsync. > I made the appropriate changes to /etc/fstab and grub.conf , > as well as /etc/sysconfig/network-scripts , > but found that there were innumerable errors > when I booted machine B into the new system, > mostly to do with creating dev's.That's normal. Anaconda does a bit of magic during the install in detecting the hardware and setting things up for it. Within limits, running kudzu will adjust some of them and sometimes it will kick off automatically when hardware differences are detected.> Also the ethernet connection, which had been eth1 on A, > was now eth0 on B, and this did not work.That will always happen even what you think is identical hardware, but if you are at the machine you can fix it manually. If kudzu runs it will set up the interfaces for dhcp and discard your old settings.> This was only a kind of experiment. > There is a problem with the partition table on machine A, > and I thought it would be useful to have a backup machine > with exactly the same setup. > > Is this a hopeless enterprise, or can it be done easily?Neither. It isn't easy and I think that is a real deficiency in Linux distributions because most people probably think they can have their backups working quickly if their machine dies. But, it also isn't hopeless - you just have to know as much about hardware and drivers as anaconda does. Or you can cheat and do an install on the new machine first and keep at least the initrd or all of /boot and perhaps modprobe.conf and a few other things. In general it is better to plan for a new install and have backups that don't overwrite the system part but there is not a clean separation between system files and you own, so plan to spend a lot of time sorting out things from your backups of /etc and /var and merging them. -- Les Mikesell lesmikesell at gmail.com
On Thursday, May 05, 2011 08:01:57 AM Brunner, Brian T. wrote:> centos-bounces at centos.org wrote: > > At Thu, 05 May 2011 07:44:52 -0400 CentOS mailing list > > Warning: dd is not a good choise if the source and desination > > drives/partitions are *different* sizes.> Different block mappings will also give you grief. > .:. The drives must be identical manufacturer and model, down to the > firmware revision. > dd is not a backup tool in the general sense.I do dd imaging quite frequently, and as long as everything is LBA48 capable and setup, I don't have problems copying partitions or whole drives between multiple drives of different sizes and manufacturers; even in instances between different interface technologies. This gets better once you're on an OS rev that treats ATA drives as SCSI, and CHS is no longer in play at all, which is the case in EL6 and Fedora revs around EL6. (At least I think that's correct; but it has been an awfully long time since I've done a CentOS 4 or 5 install on an ATA/IDE system, as all of my server systems are either SCSI or FibreChannel, physical or virtual). Having said that, I quarterly rotate two identical drives in this laptop; each quarter, I clone the currently operating drive to the secondary and to a dated whole-disk image file, and then swap the drives, putting the previous primary back into the fire safe for storage. This both wear-levels and tests the backups drives. I use a three-tiered approach to backups of my own laptop: 1.) Quarterly swapping drive clones as described above, using dd (which is faster than the slightly more friendly ddrescue, unless a bad sector is found) booted from rescue or live media of the OS that's installed (this provides a fast bare-metal base recovery that I can then update and restore from the rolling rsync in item 3); 2.) Three quarters of kept images along with the partition mapping (I use GPT, and thus use gdisk for this, which works better in my particular case than parted does (parted puts an inappropriate partition type on one of my partitions when recreating the partition map)) on multiple disks; 3.) Frequent rsyncs of /home and /etc to multiple drives, in rotation. This does mean an SELinux relabel might be required on a restore, but that's ok. For servers I do the same, but with annual images and more rigorous scheduling of tarballs of important files, along with rolling rsyncs (I've looked at rsnapshot, and backing up the backup can be somewhat interesting in that case). Dump/restore has its advantages, too, however.
On Thursday, May 05, 2011 11:35:01 AM Les Mikesell wrote:> On 5/5/2011 9:37 AM, Lamar Owen wrote: > > I do dd imaging quite frequently, and as long as everything is LBA48 capable and setup, [snippage] .... using dd .... booted from rescue or live media of the OS that's installed...> Clonezilla-live is a handy, faster way to do this.I've recast my original message slightly, as you've missed a critical point: I use the cloning tool from the rescue or live media of the OS that's installed. There are a number of reasons for this, not the least of which is that LVM, RAID, and some other things behave differently depending upon the kernel, lvm tools, etc, that's running the clone. I'm familiar with and have used clonezilla numerous times, but not for this purpose. The 'using dd ... booted from rescue or live media of the OS that's installed' part isn't as important during backup as it can be during restore. And I have been bit by that, using F12 (or 13) live media to do a C4 backup/restore; some metadata got farkled and the restore didn't 'take' until I did the restore with C4 media. Also, well, there are uses for manually-marked badblocks other than drive errors.... :-) [snip]> I always recommend backuppc for scheduled backups. It's pretty much > configure and forget and it compresses and pools all identical content > so you can keep much more history online than you would expect.I've actually thought about using DragonFly BSD and its HAMMER filesystem for the backup storage device...... quick restores rely on quickly finding what is needed, and many times I get requests like 'please restore the file that has the stuff about the instrument we built for grant so-and-so' rather than an exact filename; greppability of the backup set is a must for us. Complete, straight-dd, clones are mountable (RO, of course) and searchable, and rolling rsyncs and tarballs are searchable without a whole lot of effort. Deduplication would be nice, but it's secondary, as is the time and space spent on the backup, for our purposes.