Drive Failing... replacement on the way, how do I backup my data?

[Jason Giddens]

Hello,

I just built a new Freenas system and I have it running excellently. Its on an old computer with only 3gb of RAM so i used UFS as the filesystem. Well, now that I have everything running smoothly (SABNZB, Sickbeard, Windows Shares, etc.) I woke up this morning to a S.M.A.R.T. alert in my inbox. My drive has uncorrectable sectors. No problem, I have a replacement drive on the way from Seagate as we speak. The problem is how to I migrate my data and settings without having to build it all from scratch again? Of course the drive that is failing is the one that holds my Jail setup, my PBIs and all their directories.

So, how can I seamlessly migrate this data onto the new drive when it arrives and get back in business? I have searched the forums and find lots about ZFS snapshots, but not much about UFS.

Thanks.

 

[jgreco]

I'm guessing that the easiest, most understandable, straightforward way would be to hook up the new drive alongside the old drive, install a UFS filesystem on it via the GUI, and then use the command line and some tar- or dump-restore-fu to move your data. Once done, export the old UFS disk and update your shares to point to the new disk. But I haven't done it, so I don't know what you might run up against.

 

[cyberjock]

Be warned that if you are having uncorrectable sectors you likely are going to have corrupted data. How significant depends on what files are corrupted. I will tell you that if the jail or plugins get corrupted that will kind of suck for you. :(

 

[Jason Giddens]

The vast majority of the drive is empty so its likely the uncorrectable sectors are empty space. So, any suggestions on how to image/transfer my data and structure?

 

[cyberjock]

The vast majority of the drive is empty so its likely the uncorrectable sectors are empty space. So, any suggestions on how to image/transfer my data and structure?

I'm not sure I agree with that assessment. Uncorrectable errors are found when the hard drive has to read(or write) a sector. Unless you were running some kind of long SMART test or some other tool that reads unused areas of the disk, then those areas are almost certainly not limited to unused area. And from my experience (especially the last 3 weeks) once failures begin they usually progress very rapidly.

I had a disk that went from zero bad sectors one day to 8 the next, then 65000, then over 3 million. It was pretty interesting to watch the nightly logs and see how fast things went "bad" on one of my disk. Another had 0 bad, then 2 bad for 3 days, then over 50 million. Strangely, the zpool wasn't used much during any of the days that the disks were failing. Some people have had a few bad sectors for years without issues. I have one disk that had a boatload of bad sectors at about 110GB(its a 120GB drive) so I never format it past 100GB and I've never had any problems with the disk or the data on it.

 

[Jason Giddens]

I was running a long SMART test, so I hope that was it! Now I just need to figure out how to pull the data off cleanly before the drive fails all the way.

 

[Jason Giddens]

So, the new drive arrived and I still dont know how to migrate my data. I am happy to do the tar/dump fu but I need a pointer or two first.

 

[jgreco]

That's not a crime.

First, as carefully and as gently as you can (to protect the old drive), add the new drive to the system. Probably reboot just to be safe, make sure that the BIOS sees the new disk, etc. Everything should still be working except you now have additional storage available.

From the GUI, under Volumes, Volume Manager. You will add the new disk as a new volume of type "UFS".

Once that's done, I suggest command line from the console. "df" to see the state of your filesystems. "du" in a directory to see disk used. Just handy things to know.

You should be able to identify where your old and new filesystems are mounted with df. Let's just say "/mnt/old" and "/mnt/new" for ease.

To copy data with tar, do this:

csh# cd /mnt/new
csh# (cd /mnt/old; tar cf - .) | tar xf -

This puts you in the new filesystem's root directory. Then you create a tar running in a subprocess that's cd'd into old, and pipe it to the tar that's running here in /mnt/new.

The syntax is exceedingly important here. None of the punctuation is optional, and a lot of the spacing is significant too.

I have excluded the verbose tar option, so it will silently do its job unless there's an error, which you'll see. You can get it to be verbose with "tar cvf" instead of "tar cf" if you prefer.

Some young rude whippersnapper will no doubt point out that this is Grandpa's tar invocation and that there are now command line options to specify source and target directories. This is clearer, at least to me. :p

 

[Jason Giddens]

jgreco,

Sorry for the long pause. Finally able to execute you advice last night and something weird happened. The failing drive is called /mnt/Drive1 and the new drive to replace it is named /mnt/Drive3. I did your commands exactly as above (replacing Drive1 for old and Drive3 for new) and it appeared to work. Cut to this morning (I left the task to run over night) and something odd has happened. Both drives are 1.5TB drives (1.3 usable) and when I got to volume manager I see this:

Volume Path Used
Drive1 /mnt/Drive1 133.2 GB (17%)
Drive3 /mnt/Drive3 704.0 GB (59%)

When I go into the shell and navigate to /mnt/Drive3 I don't see any big difference in files. Any idea what all this extra data is? I cant find it.