Linux and migrating from HDD to SSD...

[mjr]

Alright...here's what I want to do.

I have an Ubuntu Linux box here at my house. I want to upgrade it, because right now it's painfully slow.

I have been considering moving from HDD to SSD, but I don't want to lose any of my data or programs on my primary HDD.

Is there a (safe) way to set up my machine to use a SSD, and basically "copy over" all my data to the SSD?

I know that'll speed things up some, but I'm also going to upgrade the CPU, motherboard, and RAM.

[RealUnimportant]

As I understand it, an SSD shouldn't be any different to a HDD in terms of configuration or usage so you should be able to use whatever systems you're already used to to copy everything across.

My MBP has a 500GB SSD and I've never treated it any differently, nor has it appeared to work differently. I know that behind the scenes there's clever algorithms that work to ensure the same areas of the drive don't get "worn out" by distributing data writes, but it's all handled behind the curtains.

[EricKei]

Well, you could theoretically just Ghost the old drive over (assuming it's smaller than the new drive) buuuut: while you can just move your data over, with any OS, when changing your boot device, your best bet really is to reinstall your OS on the new drive, reinstall your programs, and then copy over whatever else you need.

[mjr]

Quoth EricKei

Well, you could theoretically just Ghost the old drive over (assuming it's smaller than the new drive) buuuut: while you can just move your data over, with any OS, when changing your boot device, your best bet really is to reinstall your OS on the new drive, reinstall your programs, and then copy over whatever else you need.

That's a LOT of data and programs, though. I only have a 500GB primary drive on that machine (I believe), and I was thinking about buying a 1TB SSD.

I'd like to make it as painless as possible.

[lordlundar]

I thought we talked about this.

Yup: http://www.customerssuck.com/board/s...16#post1371316

And it's still applicable.

Find a mirroring/ghosting program
create the mirror image (preferably on a removable media)
format the new drive to the proper File Allocation Table
load the mirror on the new drive
confirm the mirrored drive works
scrub or retain the original.

[mjr]

Quoth lordlundar

I thought we talked about this.

Yup: http://www.customerssuck.com/board/s...16#post1371316

And it's still applicable.

Find a mirroring/ghosting program
create the mirror image (preferably on a removable media)
format the new drive to the proper File Allocation Table
load the mirror on the new drive
confirm the mirrored drive works
scrub or retain the original.

Cool. I had completely forgotten that I asked about this before.

[EricKei]

lundar - question: When ghosting/mirroring a hard drive in the past, it's been my experience that any sectors marked "bad" on the old drive will remain marked as "bad/do not use" on the new one. Is this the case on linux? Also, don't HDDs and SSD's store data in fundamentally different ways? Would this have an impact when mirroring?

mjr - What lundar said You might wanna consider some housekeeping first (e.g. file/drive integrity checks, de-duping checks, spyware scans, cleaning out temp directories, uninstalling anything you no longer use, old save game folders for stuff you don't play anymore, old video/audio files you don't need, etc) just to reduce the amount of sheer bulk in files that need to be moved over. You can always keep the old drive around as a backup, too.

[lordlundar]

Quoth EricKei

lundar - question: When ghosting/mirroring a hard drive in the past, it's been my experience that any sectors marked "bad" on the old drive will remain marked as "bad/do not use" on the new one. Is this the case on linux? Also, don't HDDs and SSD's store data in fundamentally different ways? Would this have an impact when mirroring?

For the first question, I'm not sure. I have not dealt with mirroring on Linux myself though reading through the procedure is the same.

As for the second, the differences are hardware based and largely irrelevant. What needs to be identical is the File Allocation Table format as that is software based and is what determines how the information is stored and retrieved on a software scale. How it's stored on the drive physically is a matter for the control board which interprets access requests and data transmissions between the drive and the system.

[csquared]

I wouldn't bother with a 1TB SSD. That will get expensive.

I have a 126GB SSD that has my OS and apps on it. I then have a pair of 1TB HDDs, mirrored, for /home, where I keep all my data. I use LVM for the mirroring.

As you didn't say which distro you are using. Each has it's own quirks.

Linux has all the utilities you need to copy the drive. How you do it depends on a number of things. Bare partitions or Logical Volume Management (LVM) Do you want to move to LVM? Do you want to move to something like what I have?

Short description:
Layout your partitions on the new drive
Install boot block
Copy file from - to each partition.
Swap drives New drive need to be at the same device location as old was. i.e. /dev/sda
Boot to new drive.

EricKei - Usually not. Block relocation is usually handled at the drive. If you have used all your spare blocks and the file system is now reallocating, then a volume/block level copy will copy the flags. A file level copy won't.

[mjr]

Quoth csquared

I wouldn't bother with a 1TB SSD. That will get expensive.

As you didn't say which distro you are using. Each has it's own quirks.

Linux has all the utilities you need to copy the drive. How you do it depends on a number of things. Bare partitions or Logical Volume Management (LVM) Do you want to move to LVM? Do you want to move to something like what I have?

I'm using Ubuntu, latest Desktop version.

All I really want to do is take everything on my HDD and copy it to a SSD, and have it work.

Of course, since my Linux computer is so slow right now in its setup, simply upgrading the processor, RAM, and motherboard may make it sufficiently fast for me.