Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Several of our development servers have flaky SSDs that need to be replaced. The machines are still usable, but we see lots of errors in dmesg, and every once in a while they need to be rebooted because of I/O errors. We have new SSDs (proven to be reliable in other servers) ready to be installed.

Some facts:

  • The servers run both Ubuntu 10.04 and 12.04.

  • There are about half a dozen different accounts that ideally would be restored to the new disks.

  • Much of the data is in git repositories, but there are also many files not controlled by git.

  • Many extra packages have been installed, most of which are documented in the various readme files of the projects.

  • There is still time to make backups of any and all files, and plenty of other servers on which to store the backups.

  • If restoration is too difficult, we can simply pull down the git repositories and reconfigure the new systems manually, though we would prefer not to.

What I am looking for are recommendations for approaches to restoring the machines to their current state after the new drives go in. Some more specific questions:

  • Should I just tar up / or /home?

  • If I tar up /home, how do I preserve the user IDs?

  • Is it better to just tar up individual accounts (tar zcvf user.tgz /home/user/*) and restore them after adding each user to the new system?

I am hoping that there are standard approaches to this problem I can take. I read this question, but it wasn't quite my problem. This other question recommends clonezilla or dd. Is that the way to go? I am a little leery of cloning the disk because I want to avoid propagating corrupt files that went bad due to the flaky nature of the current disks.

share|improve this question
BTW, as I was creating tarballs of a 1.9 GB home directory on one of the flaky disks that had over 30 GB free, I got disk errors saying there was not enough space to store the tarball. That is one messed up SSD. I was able to delete some unneeded files to bring the tarball down to a size that could be stored safely, so nothing important (but time) will be lost. – Randall Cook Feb 21 '13 at 6:56
up vote 0 down vote accepted

I would use tar

Make the archive

tar -pcvzf home.tar.gz /home

Extract the archive

tar -pxvz home.tar.gz /home


p = Preserve permissions
c = Create archive
x = Extract archive
v = Verbose (show file names while making the archive)
z = Use gzip
f = Archive file name

See also

share|improve this answer
Won't cloning the entire home directory lead to misassigned files if on the new disk the users have different user IDs? In other words, if the user rcook has id 1002 on the old disk, and gets userid 1001 on the new disk, the decompressed /home/rcook directory will be filled with 1002-owned files, inaccessible to the new 1001 rcook user, right? – Randall Cook Feb 21 '13 at 0:17
Yes, Linux associates users by UID, not user name. If the user names are not the same across installs you will need to be very careful. – bodhi.zazen Feb 21 '13 at 3:08

Clonezilla is OK if your target disk is of similar or larger size than the flaky one. And if you have a bootable CD reader of course.

share|improve this answer
Clonezilla will also work from Live USB (see here Good luck – Geppettvs D'Constanzo Feb 20 '13 at 20:26
Thanks for the quick answer. Considering that the source disk is flaky, should I even bother cloning it? Won't that put me at risk of cloning corrupted files? – Randall Cook Feb 21 '13 at 0:11
Well, if the HD itself has damaged sectors, you might end ub with corrupted FILES, but the filesystem as a whole should be OK. – piffy Feb 21 '13 at 15:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.