Accidentally rm'd volume - how to restore from snapshots or replication?

[scurrier]

Whelp, I'm dumb.

Through an exceedingly unlikely series of events, I went and stupidly did a rm -r on one of my zfs volumes from the shell. When I realized what I did, I killed the rm.

I have been keeping snapshots of important datasets on that volume (but not the volume itself) as well as replicating those to another volume on a different disk set. So I know my data is still here somewhere, I am keeping at least 2 copies of it.

Question is: How should I restore now?

 

[scurrier]

Interestingly, it looks like nothing was even deleted. Maybe it was first gathering information to perform the delete and not actually deleting before I cancelled it? Still, I'd prefer to restore to make sure everything's clean.
Also, the snapshots that were made automatically subsequent to this mistake don't seem to indicate any changes via the refer or used properties. I don't understand why nothing's showing - maybe because I attacked the volume instead of files inside it, thus circumventing the snapshot mechanism?

 

[scurrier]

To be more clear about what I did- I have a volume named firstvol:

Code:

/mnt/firstvol

I accidentally ran this:

Code:

rm -r /mnt/firstvol

(I did this accidentally by not being careful about reusing the text of a previous command using the up arrow. I was on my phone with tiny text I can barely read.)

I have snapshots of lower level datasets like:

Code:

/mnt/firstvol/firstmain
/mnt/firstvol/serverfiles

...but not of stuff like:

Code:

/mnt/firstvol/media

 

[scurrier]

My guess is that I may have deleted files and folders in the volume, but probably did not delete anything that would affect the basic integrity of the volume or system. So to restore, I should just copy the files over from the backup? I'm a little afraid that this will be viewed as totally new data and will bloat my disk space because old snapshots will be hanging on to old data, though.

 

[scurrier]

Looks like I found a better solution than doing some awkward copying from a clone of the backup snapshots. I can rollback using these commands: http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r4m/index.html
This would have the advantage of being at the zfs level, so should definitely not result in bloating further snapshots.
I'd much appreciate someone's verification that I'm on the right track here.

 

[depasseg]

I was going to suggest, that in this situation, you use the rollback, assuming you have snapshots that are current. It sounds like you have child datasets as well, is that correct? If so, I hope you have either recursive snapshots enabled, or snapshot schedules for all the children. When you do the rollback, I don't think the children will get rolled back, so you would need to do those as well.

 

[scurrier]

Yes, there are child datasets. I have snapshots enabled on the children only. I would have rolled them back individually, but I read that rm runs an atomic operation on each file and either fully deletes or fully does not delete. So, instead, I ran the following

Code:

diff --brief -r firstmain firstmain-auto-20161106.2238-30h-clone

This gave me a report on all the files that were different between the snapshot and the current dataset. For all my important datasets, it looked like nothing had changed. So the rm either only terrorized by non-important directories or never exited the tree crawling stage of the rm.

Thanks for the help, I think I know what to do now (probably nothing, but may roll back just to be sure.)