SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I will be migrating a host from SuSE 9.3 to Oracle Enterprise Linux.
Before doing it, I'd REALLY like to have a solid backout plan that will allow me to go back to where I was before the upgrade (or downgrade depending on your viewpoint).
I am looking for a way to take the existing system and make a bare metal recovery image of it (iso images?) that can be booted from and have a system restored exactly the way it was.
Anybody have experience with this... more importantly, anybody have experience actually having to use the bare metal image to go back to the previous system?
I will be migrating a host from SuSE 9.3 to Oracle Enterprise Linux.
Before doing it, I'd REALLY like to have a solid backout plan that will allow me to go back to where I was before the upgrade (or downgrade depending on your viewpoint).
I am looking for a way to take the existing system and make a bare metal recovery image of it (iso images?) that can be booted from and have a system restored exactly the way it was.
Anybody have experience with this... more importantly, anybody have experience actually having to use the bare metal image to go back to the previous system?
1. you need a basic linux to boot the system. I use poppy linux in a usb flash disk (or dsl-n linux). You can use any of the live cd or the recovery cd of your distro. I use the same system to backup/restore. So to backup I boot linux from the poppy usb and backup to a usb attach hard disk. To restore I boot from the poppy usb and restore from the usb attached HD
2. Tools to backup.
DD it works very well. If you have two partition you will have to use dd for each one. It does not go accross file systems or partition.
For recovery you reverse the process and you are done.
tar or cpio. It allows you to have all partition in one file. The restore will restore to each partition.
3. If you use tar you will have to restore grub stage1 otherwise it will not boot. If you use dd you will not need it because it will produce an exact copy.
If you want to go in this direction first create some linux to backup. Look at poppy and dsl-n both are very small and very easy and fast to install. After you hve it please post if you need any help to run dd or tar.
DD it works very well. If you have two partition you will have to use dd for each one. It does not go accross file systems or partition.
For recovery you reverse the process and you are done.-=terry(Denver)=-
The system disk is carved up into 6 partitions total (sda1 thru sda6). What I'm testing right now is to try and do a dd of the entire drive (sda).
Boot linux from CD
mount a large NFS volume
dd if=/dev/sda of=/nfs-mount/sdafile
Just out of curiosity, could you use rsync on all files in all partitions of a drive, and save them into on tar file? Basically, just save a copy of /dev/hdb and move this to /dev/hda as y2kram was attempting to perform in a similar fashion? I was reading this post, and I actually plan on performing a similar type of task, where I would like to move the entire contents of /dev/hdb (openSuSE 10.2 installation) and move them to /dev/hda. Or, would it be possible to simply replicate the same partitions on /dev/hda, along with file system structure, as those found on /dev/hdb and move the partitions this way? For example, save tars of /dev/hdb1, hdb2, and hdb3, and move them to /dev/hda1, hda2, and hda3, respectively?
Last edited by swampdog2002; 10-04-2007 at 01:28 PM.
Assuming that hda and hdb are on the same physical machine, just boot a LiveCD, create a filesystem (any, not necessarily the same) on hda* and cp -a hdb* to hda* one by one. Adjust /etc/fstab, mess around with the boot manager and off you go.
Plan B is using Partition Image (partimage) which is on the SystemRescueCd.
Boot the CD
mount the NFS volume for backup
create a backup image of each partition
But I believe the original plan gets everything, including the MBR, etc.
The oblective is:
If the new OS fails to do what it needs, I can boot the CD, mount the NFS volume, then dd the image back and I haven't lost a single byte off the spindle from where it was before the upgrade. That's why I'm trying the dd of /dev/sda as a single large image file.
grab a second hard disk
dd if=/dev/hda1 of=/dev/hda2
now use this second hard disk to upgrade degrade experiment what ever you wish your data on disk 1 is untouched
if the experiment is successful you can use disk 2 further
use disk 1 as primary backup
grab a second hard disk
dd if=/dev/hda1 of=/dev/hda2
now use this second hard disk to upgrade degrade experiment what ever you wish your data on disk 1 is untouched
if the experiment is successful you can use disk 2 further
use disk 1 as primary backup
Wish it was that easy... the system has 4 drive slots (and 4 drives!) 3 drives striped @ raid 5 w/1 hot standby. The expensive solution is to buy 3 new drives and save the original 3 "just in case". So that option really would be the last resort.
Wish it was that easy... the system has 4 drive slots (and 4 drives!) 3 drives striped @ raid 5 w/1 hot standby. The expensive solution is to buy 3 new drives and save the original 3 "just in case". So that option really would be the last resort.
One more reason NOT to use dd.
cp and rsync let you move to a non-LVM environment.
One more reason NOT to use dd.
cp and rsync let you move to a non-LVM environment.
It's a H/W raid group (not S/W Vol group).
The filesystems on the current system are reiser and the new filesystems will be ext3. If I have to restore everything, it must go back exactly the way it was. I don't want just the contents of the partitions, I want the disk structures as well so all I have to do is dd it back and reboot.
It's a critical server (part of a 4 node production Oracle RAC cluster) and I won't have a lot of (ie; any) time to figure out why it isn't coming back up after a restore.
Space isn't an issue, I have a 1TB NFS volume just for this back-out plan.
I guess it boils down to: what would be more solid or more reliable, and introduce less opportunities for problems, than a dd of the entire disk?
After dd'ing the entire disk to an NFS mount, I deleted a couple of partitions (using fdisk) and wrote/saved the partition table. Verified that the partitions were gone by looking at /proc/partitions.
Then mounted the NFS volume back on the system and did a dd back of the image to the /dev/sda disk.
When I looked at the /proc/partitions, I saw that the partitions I deleted were still missing, so I went into fdisk and listed the partition table (p) and saw that all 6 partitions were back, so I just wrote/saved it (w) and /proc/partitions shows that they were all restored.
Rebooted and the system came up.
Looks like this is a fairly solid solution to image the entire disk.
Or, would it be possible to simply replicate the same partitions on /dev/hda, along with file system structure, as those found on /dev/hdb and move the partitions this way? For example, save tars of /dev/hdb1, hdb2, and hdb3, and move them to /dev/hda1, hda2, and hda3, respectively?
"partimage" is a good tool if all you want are the actual partitions. But the target disk partition must already be defined (using fdisk?) and must be at least the same size (or larger) than the original in order to restore the image to that partition.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.