XigmaNAS

The motherboard in my server failed and created a new machine and now trying to get my data back online.

Since it was a new system, I started from a fresh NAS4Free install and have been configuring things back to the nominal state.

Started the process using "Disks|Management|Clear config and Import software raid disks" as I had a mixture of ZFS and SoftRaid file systems.

The import was successful in listing all of the disks. Compared the serial numbers to make sure each of the drives appeared on the Device as they did in the old system.

The following is were I think I went wrong, instead of going to the "Disks|ZFS|Configuration|Detected" and trying to import the pool, I went to the "Disks|ZFS|Pools|Virtual device|Add" and created a Virtual Device with all the same parameters as the old system and then using Disks|ZFS|Pools|Management added the virtual device to a pool. Should have known things were wrong as I was getting an error when I tried adding the pool, stating that it was already an active pool. Some searching lead me to believe that this was expected when you can export the pool before migration (such as in a motherboard failure), so I continued on using the force (-f) checkbox.

I was able to mount my pool but there was no data there.

Is there anyway to retroactively go back and perform the ZFS import? Any path for data recovery? I have one very upset wife right now (Last successful backup was 6 months ago, learning many lesson the wrong way).

Seems you created a New pool and shredded the old

Here are a few hints how to possibly safe it,
Scroll down the page to the recovery topic

http://docs.huihoo.com/opensolaris/sola ... 04s06.html

Silly question, why didn't you simply restored the config.xml of your old system, after setting up the new N4F installation ?

No silly questions, I have just made some very silly mistakes.

The problem with NAS4Freee, is that for the most part it just runs, doesn't give me much of a chance to retain my knowledge between maintenance sessions.

I thought with the new motherboard (different vendor and south bridges) along with upgrading from 9.1.X to 9.2.X that using the old config file would not work, and instead thought it would be "safer" to just redo it. Nothing more dangerous then a half educated admin.

The zpool import -D examples don't seem to cover my case where the pool has been destroyed and a new pool created and you need to revert to the old pool.

gmccone wrote:The zpool import -D examples don't seem to cover my case where the pool has been destroyed and a new pool created and you need to revert to the old pool.

YES, new metadata from new crated pool are stored in your disk so is really rare/dificult that your data can be recovered.

your only option is a backup or a professional grade recovery enterprise ( lot of $$$)

Next time you'll know... :-/

Actually it is very easy to switch mainboards, usually you just clear config and import disks first, then you synchronize your ZFS pool and that's it.
I did this >five times so far without any problems. Now I learned that it is even safer when you first export your pool, I will do this as well the next time I change some hardware.
But I would never touch this without having a Backup of my Pool.

crowi wrote: Now I learned that it is even safer when you first export your pool, I will do this as well the next time I change some hardware.

if you have the embedded install you dont need to export your pool.
it gets exported on shutdown and imported on start because the zfs information can not be stored on the drive.

see the zfs start script.

Hi bossman,

I have full install :-/
Do I need to worry about? I only shut down my server and changed the mainboards, so far everything seems to work and I also scrubbed recently...

btw, I will move to embedded as soon as I find the time to do it.

If you do not export the storage pool before removing the drives, you will not be able to import the drives on the new system, and you might not have gotten all unwritten data flushed to disk. Even though the data will remain consistent due to the nature of the filesystem, when importing, it will appear to the old system as a faulted pool. Further, the destination system will refuse to import a pool that has not been explicitly exported. This is to prevent race conditions with network attached storage that may be already using the pool.

Okay, now I got it. BUt I 'just' changed the mainboard not the N4F system, the System disk just booted with the 'old' system and juggled with the drive names a bit.
The pool status showed no fault at all, I could easily import and synchronize it. ':)

But thanks(!), I will keep this in mind in the future!!!

Thanks everyone for your feedback.

I called some data recovery places and they all said the data could be recovered, but the quote was somewhere between $3k - $16k. Looks like I will have become a data entry monkey for my wife for the next few weeks to get everything caught back up.

I have learned a valuable lesson. I tool is only as good as it user.