In our environment, we have configured software raid for root disk. Now we are planning to upgrade the patch of OS but question is here if something unexpected happen then how we can recover the OS?

OS version is SLES10.3

Suppose we have two disks

/dev/sda & /dev/sdb and raid1 is configured like
/dev/md0 (/dev/sda1 & /dev/sdb1) - /boot
/dev/md1 (/dev/sda2 & /dev/sdb2) - /home
/dev/md2 (/dev/sda3 & /dev/sdb3) – swap
/dev/md3 (/dev/sda4 & /dev/sdb4) - /

and when will start OS upgrade then we will detach the secondary disk from the software raid but now how we can boot the OS from secondary disk if something happened to primary disk or how to roll back the OS patch upgrade?

So here we want to boot the OS from secondary disk and data should sync from secondary disk to primary disk.

But please suggest if any other best practice that we can follow.

Regards
Sandeep Sharma

You make sure you have a backup of EVERYTHING first, then you don't have to worry.
...which makes this question easy to figure out. You're using SLES...so, you're paying for support from SuSE/Novell. Give them a call, this is the sort of thing you're paying them for.
Once begun, you don't 'roll back' an OS upgrade. There are too many moving pieces, as a rule, and you'll probably be left with an unstable system. Best advice would be to make a good, solid backup of the system first, and VERIFY the backup. After that, do a clean install of the new OS, and restore your data. In over 25 years, I have never had a good experience in doing an in-place upgrade...it has always led to issues later on, if they worked at all. A clean install will leave you with a more stable system, in my opinion.

And since you want a quick roll-back, you're in a good spot for the best solution: remove the hard-drives from the existing system, and put in new, blank drives. If something goes wrong, all you've got to do is a disk-swap and the system is back where it was before you started. Disks are cheap these days, and (at worst), you'll be left with a few spare hard drives after the upgrade.

2 members found this post helpful.

TB0ne,

This was written like a Bible!
I agree with every part of it.

Last time when I was upgrading customer's box I was forced to upgrade their system because of a security issue and guess what has happened? The non-free Debian package "killed" the network interface driver in the initramd.
I had to rebuild the initramd manually because the upgrade "ruined" it.
Of course they didn't have backup and of course it had to be done asap because of a security issue.
And it had cpanel with God knows how many domains on the box!

No one can offer more than 2-3 hours down time but when the crack comes they start crying like a children and claims "WE LOSE A MILLION A DAY! DON'T YOU UNDERSTAND THIS???".

I guess you've heard this before many times from the owners who could not afford few hundred more bucks for a proper backup.

Yes that is true, you should always have backup before doing any activity.

But here i am curious to know the way if we can recover the OS and if it is not so then why we are using software raid?
So still i am doing some testing over software raid if it possible but please let me know if anyone have any solution which could helps us in better way.

I think in this particular instance, part of the reason you are receiving harsh feedback is that you are trying to use raid in a manner in which it wasn't intended. Raid was meant to increase availability and uptime, not as a means of backup.

Your question, though, of if the primary disk were to fail and be removed how could you boot the system on the secondary is still valid. Recently I started working on a rebuild of one of my systems using Centos and a software based raid 1. When I initially created the system, from a clean format, I had to pick which device to install the bootloader on. Initially I tried putting it on the md0 (raid) device as I had done with the corresponding Ubuntu machine and found that it wouldn't boot. Instead, I had to put the boot loader on the first disk only and I think that this is the crux of your concern here.

Based upon this article, it appears that there may be a bug in the bootloader setup in RH based system, where the bootloader only gets installed on the first drive. It discusses manually running grub setup on the secondary drive to solve this problem. This seems to be confirmed by the Centos Wiki that says to run this proceedure.

Alternatively, you could use a rescue method of boot or a liveCD and then manually mount the partitions and switch to that system. This method is spelled out in the Centos wiki for creating a raid 1 from a single device. While not exactly what your trying to do, the steps involved should get you clear if you wind up stuck in the mud.

Noway2 hit it on the head. RAID is NOT meant to replace backups, only to keep your system going in the event of a disk failure. If you're talking about a bare-metal type recovery, then yes. Look in to any of the easily-found tools to do this (mondoarchive, systemimager, mkcdrec), and go from there. If you use a 'real' backup system (Like Tivoli or Networker), you may also have the options to do BMR-type activities from that.

Again (and this has been said by MANY folks here, MANY times), do a clean install, don't do an upgrade. It's far cleaner and leaves you with a better system. Want a roll-back option? Then buy other disks as I suggested, and you can roll back in 15 minutes, with total confidence; disks are cheap, you can buy 1TB disks for $69, so why even bother thinking about it, if it's for your company? This will be a usable, tangible asset for them..it's not like you're wasting money.

And again...you're using SLES, which is a VENDOR SUPPORTED OS. Have you called Novell/SuSE yet???

Finally i got the solution.

I have used Clonezilla which is very useful for backup and restore.
This solution is useful if you are going to perform major activity on physical server like OS patch upgrade etc.

http://clonezilla.org/


Regards
Sandeep Sharma

'Finally'??? You were given this information (doing a full backup), several times.