Migrate ubuntu server to new hardware

If I clone the drive and connect it to the new system with different hardware configuration, won't it cause any problem as the cloned os will be having previous hardware information(different sizes of ram, cpu of different speed, .....)?.


This way what tool is best for copying and what are the directories I should and shouldn't copy on the orginal system.

It will adjust.  The only issue you may have will deal with the graphics.  You would likely need to reconfigure XORG. Provided you did not recompile the kernel (create a custom kernel).

As far as what to copy and what not to copy depends on what your intentions are.  Is the new hardware is a direct replacement?

You would/could use DD to copy the partitions and depending on the size could prove tedious.

A clean install of the newer version of Ubuntu and then configuring the server/system to perform the same tasks/service, may be beneficial.

Is the new hardware is a direct replacement?:
Actually to say it's not replacement, but having the old one I want to move entire os to the new computer for better performance with all what are present on the old system.

Clone:
Why not to use 'ddrescue' instead 'dd'?. I tried 'ddrescue' and had the following problem which was not answered by anyone. Actually it's not a problem but need some tricks or tips:
- While using ddrescue, there is a change to wrongly specify devices(/dev/sda /dev/sdb) even checking with fdisk:- Any tricks
- After properly cloning the drives, sometimes the system boots from original disk and sometimes from duplicate after every restart:- Here I need tips/tricks. It should only boot from original disk.

I mean to say chance instead change

You would/should not leave the cloned disk in the system as its presence supposed to be temporary.

I have not seen when the system boots from the clone drive unless your drives are connected out of order i.e. the original drive is connected to SATA 2 and you connected the drive to which you will clone on sata 1 or 0.  When the system booted, it will first detect the cloned drive and boot from it.

It is a good thing to make sure the cloned drive works by at least letting it boot the original system.

Note that if you are using static IPs, you can not have both systems on at the same time.  IMHO, instead of cloning, I would actually install the newer OS anew.  Configure the services/etc. and then when it is ready, will transfer the data from the old to the new.

Presumably you would have to eventually update the 9. to 10. and why not do it where you can test the functionality/configuration without an impact on the current functionality?

Good answers!. Actually to say, I have to migrate the system to new hardware and as well as I'm working on server recovery project. So for this reason,  I'm even trying to provide High Availability of servers like if any server gets down, I should immediately come up with another with all services

@arnold:
I'm thinking to synchronize two disks after having cloned successfully. If I remove the cloned one, I could not replicate the changes made on the original disk to the duplicate. And one trick I'm expecting from you. That is, if I use dd or ddrescue, I may wrongly specify devices(/dev/sda /dev/sdb) and as for this reason I'm a bit afraid to do so. So any trick here, because I've to do this even for cloud servers.


mccracky:
I can use 'tar' If I'm given extra servers for each and I'm not sure here that I'll have more servers.

I think I cannot use Clonezilla as I'll have to do this for even cloud servers which I will not have direct access to them and I'll connect them via ssh.

if represents the input file the source and of is the output file or the clone

http://www.ehow.com/how_4924091_clone-hard-drive-linux.html

dd if=/dev/sda of=/dev/sdb
But this will take quite some time depending on the size of the drive.

If you partition the drive to which you will clone the data, you could use the dump | restore mechanism
http://linux.die.net/man/8/dump
http://linux.die.net/man/8/restore

ssh root@oldserver dump -0f /dev/sda1 - | restore rf -

Thanks. For replicating, I thought of using rsync and I'm using it, scheduling a cron job without prompting for ssh password.

rsync -avP /usr/ 192.168.2.100:/usr
rsync -avP /etc/ 192.168.2.100:/etc
------------------------------------------
-------------------------------------------

But I'm wondering if it is possible to modify the above entries to one line. And one thing, before doing rsync should I stop all the services?

You might be able to combine things into one line with the --include and --exclude options, but another thing would be to (on both machines) use the mount --bind command something like:

mkdir -p /mnt/rsyncmounts/etc
mkdir -p /mnt/rsyncmounts/usr
mount --bind /usr /mnt/rsyncmounts/usr
mount --bind /etc /mnt/rsyncmounts/etc

and then use:

rsync -avP /mnt/rsyncmounts/ 192.168.2.100:/mnt/rsyncmounts/

oh, and you shouldn't need to stop any services for these rsyncs.  /etc/ and /usr/ mounts usually aren't changing that much (the /var would be changing much more).  

@mccracky:

Wow!. Smart thinking and it's really good to go. I've few questions regarding the following you suggested:
mkdir -p /mnt/rsyncmounts/etc
mkdir -p /mnt/rsyncmounts/usr
mount --bind /usr /mnt/rsyncmounts/usr
mount --bind /etc /mnt/rsyncmounts/etc

1. Would it occupy any extra space(I think yes)
2. Any changes made to ' /mnt/rsyncmounts/' are replicate to the original directories /usr, /etc, ...?----I feel it would be better if it has one way sync. Like,
any chnages made to /mnt/rsyncmounts/ SHOULD'NT be replicated under / directories AND
any changes made to / SHOULD be replicated to /mnt/rsyncmounts/. Any tips here?

Ok. How to unbind /mnt/rsyncmounts/*

Any changes to the files under the bind mounts would be replicated as it is just a duplicate inode to the same file.  They actually are the exact same files under /mnt/rsyncmounts as under the /etc and /usr directories.  This also means that is doesn't occupy any extra space at all.

If you want the replication to be one way, then you would need to copy the files rather than mount --bind them and that would occupy extra space and another level of rsync commands. Once again, the mount --bind just adds another reference to access the files.  They are the exact same files.

unmounting should just be a:

umount /mnt/rsyncmounts/usr
umount /mnt/rsyncmounts/etc

Before asking I tried umount but it said it cannot be unmounted. I think I was in that directory.

One more thing if I use 'tar' or 'rsync' , will the iptable rules applied to the source are also applied to the destination?

re: umount:  umount will always fail if part of the partition is in use (when you are in the directory it is "in use").

re: iptables: it depends how you apply the rules in the first place.  It probably will as both the start up scripts and configuration files are usually somewhere under /etc.

mccracky: Thanks a lot. I'm not using any iptables startup script but I checked applying iptable rules on source, then creating a tar and extracting it on destination. The destination has default rules. It's ok here.

As Arnold suggested would you like to suggest any more way or tool other than tar and rsync for migrating ubuntu cloud servers remotely

This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.