Crash when importing

[patmuk]

Good idea - unfortunately the receiving dataset has to be empty.
I have no disk left, and detach does not work with a read-only pool.

To set up a new pool and receive the snapshot there I would need to
a) detach a disk from another pool
or
b) export the crashing pool and create a new pool, using one of the disks of the crashing pool.

I wonder if I would be able to import the pool readonly if a disk is missing ... but I saved all data already.
Now it is more about avoiding that some files where corrupt.

[Brendon]

The corruption issue didn't effect files, rather some meta-data to do with deletion. If you just upgraded from ~1.3.x to 1.5.x then there is some chance you have this issue, otherwise its likely something else. If you have a different failure, then in the absence of a crash dump we cant really tell you what has happened.

Cheers
Brendon

[patmuk]

Hi,

I got it fixed

It was a 3-disk-mirror.
I created a new pool with one of the disks of the mirror.
Next I mounted both, the corrupt zpool and the new pool.
Using zsf send |receive
I could get all data to the new pool.
Now I will attach another disk from the corrupt pool and finally destroy and recreate the old pool.

My learning is now that I rather have a 1-disk pool and use send/receive with a cron job to create a mirror.
optimally I would have 2 2.disk mirrors ... but I don't want to buy the needed disks.
The drawback would be that when a disk fails in between the send/receive runs all data which has not been send is lost ... but my important data is on that 2-disk-mirror.

@Brandon: Yes, I updated from 1.3 to 1.5, though I executed the uninstall-script in between.
The last time it crashed I saw in the log that no crash dump could be written

Thanks for your thoughts, that really helped!!

[Brendon]

Ideally you would keep you data on a dataset with some redundancy (mirror, raidz), and consider sending it to a weaker setup. I keep my data on a raidz and backup to a couple of single disk datasets.

- Brendon

[patmuk]

Thanks for sharing! Ok, that somehow confirms my idea. For my important (non-retrievable data, like photos) I will use a 2-disk-mirror with a 1-disk-backup dataset. For the rest I will use a 1-disk-dataset for the live data and a 1-disk-dataset for the backup.
Next I will change my cron script to not only create snapshots but send them to the backup datasets as well.
Thus I have basically the same disk-redundancy as before, but a gap of x minutes (time in between writing new data and making & sending the snapshot to the backup) in which data could get lost. But with an additional protection from metadata corruption of a dataset.

Thanks a lot Brendon.