Migrating existing partitions to SSD + HDD
 

I have a Lenovo T530 i5 that I purchased last fall with 4GB ram and a 500GB 7200rpm hard drive, with the intention of upgrading it to 16GB and an 256gb SSD when time/funds allowed. That time is now.

The machine is currently multi-boot Windows 7 Pro, Ubuntu 12.10, openSuSE 12.2 and Linux Mint 14. After a lot of initial fussing around, the latter two get used very little if at all, so I will probably be going to just a dual-boot config. The hard drive is split up with approx. 100GB for Win7, 20GB for each of the Linux distros, 15GB for the Windows recovery partition, 5GB for swap, and the remainder accessible under /srv/data in the various distros.

When I initially got this machine, the very first thing I did was use clonezilla to image the HDD and store it to a NAS. As I finished doing the various updates, partitioning, more updates, installing other distros, etc. I continued to do periodic images with clonezilla, so I have a pretty good set of backup images that I can go back to for restoration if need be. The user /home directory is backed up using duplicity (Deja Backup) under Ubuntu, also to the NAS.

What I want to end up with is the SSD as the primary drive, with the Windows system and recover partitions, and Linux partitions as necessary in the remainder, using LVM. The current HDD will be re-purposed and mounted in a caddy in the optical bay under /srv, probably formatted NTFS so its accessible under both Win7 and Linux.

I was thinking of taking another run with clonezilla and imaging the Win7 install, the Ubuntu install, and the /srv/data partition to the NAS one final time. After that... install the new SSD, restore the necessary partitions to it via clonezilla to get Win7 running again, and then re-install Ubuntu from scratch in the remaining space, and restore /home/$user from the NAS using duplicity. The major fly in the ointment here is getting the linux install back to its previous state, as far as installed programs, PPAs, etc.

What I'm after here is any suggestions as to any glaring faults with the above schema, and ideas on how to get from where I am to where I want to be when all the bits get here.

Thanks,

Monte

I would not use SSD for recovery partitions.
probably here you can find some tips.

Most of what I've been reading seems to recommend against using SSD for partitions that would see a lot of write activity - swap, /tmp, etc. Why would you not use it for the Windows system recovery partition, which for all intents and purposes, should be static and see almost no writes once completed? Other than being somewhat of a waste of space in Linux terms, that is ;)

just because the recovery info is not used at all. So I would suggest you to install your frequently used apps (binaries, libs ...) onto ssd and use hd for temp files, caches, configs, logs and other frequently modified files/dirs (not to speak about ramdisks and tmpfs).

For example the browser and its plugins can be stored on ssd, the cookies, temporary downloaded files and others on tmpfs or hd.
or, a game can be stored on ssd, the saved games and related on hd...

If you will be installing Ubuntu from scratch, you will be re-installing your programs anyway. User adjustable settings for programs will be contained in hidden directories in your HOME directory. Make sure they are being backed up as well.

If you have built packages from source, you can back up /usr/local/ and maybe /opt/.

You might want to retain a list of the repositories you use, if they aren't the official repositories.

Perhaps back up your old /etc/fstab file, so you can use it as a reference to manually mount the old HDD partitions. You may find it easier to restore files from your old drive than from backups on the NAS. Format the old drive later when you are sure you have what you need.

When you perform a backup, consider running "sudo fdisk -l >disk.list" so you have the start and end points of your partitions. If the partition table gets zeroed out, you can simply re-enter the correct start/end values.

Good Luck!

Any thoughts on the necessity of over-provisioning the drive by purposely not allocating all the available space to partitions? It appears that most new drives have ~7% over-provisioning already built in, but I've seen some references to leaving as much as 10-20% unallocated for this purpose...

Thanks,

Monte

Well... its done... but there are some residual problems.

They don't stem from the SSD itself, but some of the gyrations I had to go thru to get the partitions shrunk and then copied over to the new drive - had to use some Windows software (Macrium Reflect) as things didn't seem to end up bootable when using clonezilla). Now I have the 256GB SSD as /dev/sda, booting Win7 and Ubuntu 12.10 as planned, with the 500GB 7200 rpm HDD mounted in an UltraBay drive caddy as /dev/sdb - formatted as ntfs (so I can access files stored there from either OS) and mounted under /srv/data in Linux. After shrinking partitions and cloning them to the SSD, I deleted some other (linux) partitions I had on there, with the intention of expanding the Ubuntu '/' partition (carefully, using a bootable live USB image rescue 'disc')... but now I'm having issues even seeing any partitions on the SSD inside gparted, and sfdisk -l complains about overlapping partitions.

So now it looks like I'm back to the point of having to back up the partitions to an external drive, reformat the disk and set up the partitions from scratch, and then restore the partitions from the external storage. Kind of a bummer since things 'seem' to be working otherwise.

The question going thru my mind now is... will backing up and restoring the disk partition by partition (as opposed to a whole-disk image) using clonezilla work, or will the partitions end up overlapping once again after restoration?