Due to a necessary upgrade to larger disks in a Dell server I'd like to image the existing CentOS 5.3 installation and recover this onto new disks.
Because the existing disks are RAID-1 and take up both slots in the machine I can't simultaneously have the new and old disks in at the same time. It's a Dell R300.
I can take server down and I'm comfortable using rescue disks for CentOS, and creating partitions etc, just a question of the data transfer. It'll likely either be to a USB disk or over NFS to another server (NFS probably preferred, as Gigabit so faster).
I presume this is something like running rsync/tar with the right options on the various partitions - anyone done this and can suggest suitable commands to achieve it?
thanks
Barnaby
It may be overkill but I used to love systemimager for this kind of work - especially for deploying cloned systems over and over again:
http://wiki.systemimager.org/index.php/Main_Page
Why not break the RAID-1 and stick in one of the new disks? If you're willing to take downtime anyway, it's not as though an inopportune disk failure would cause anything awful to happen.
How about CloneZilla? Would that suit you?
Hope this helps, Best regards, Tom.
I've done this. With Dell's RAID controller, the RAID volume appears as a single disk to the O/S. This allows most any imaging software to treat it as a single disk. I used G4L (can be used to image any O/S, not just Linux) to image to a nearby FTP server or USB disk, swap out disks, rebuilt RAID volume, and then image back to the upgraded disks.
If you image the entire RAID volume, it will do the partitioning for you. However you will have exactly the same size partitions as before, which may be limiting if you are replacing with larger disks. You can add additional partitions later or bump out the last partition with gparted. With foresight, putting Swap and /var as the last partitions allows some more flexibility here.
The alternative is to image one partition at a time. That is more tedious, but allows you great flexibility in laying out your new partition scheme- as long as each new partition is the same size or larger than the backed-up partition!
To update this question with a successful outcome, I ended up using a combination of the above advice. I picked this solution because some downtime was fine in my situation (I was more concerned with spending less time at the data centre!) and wanted to be definitely sure it'd work.
... profit! :-)
cheers for the help!