root fs and /data deleted, but .system on old boot looks interesting. Is it what I think?

[Stilez]

Okayyyy. So. Not to put too fine a point on it, I've officially done my unix initiation. You know, the one where you type 'rm -Rfd stuff' and delete / by mistake? :D:D:D

There will now be a brief but mandatory pause for 5 million forum users to die laughing

#!/bin/sh
pause
lol > /dev/random
other_stuff_here
esuap

In mitigation, I honestly don't know how it happened, as I was cd'd into a data subdir with a couple of thousand pointless HDD image backups in many dirs and no symlinks, and the command was 'find . -name 'text' -exec rm...{} \; and not mistyped. I'm not completely naïve. Well, maybe today I am..... but I'm also not too upset because

1. 15 min x 7 day rolling snaps on the entire dataset and before I could hit ctrl-C the output was filled with a ton of "cannot delete from read-only dataset", so thanks to the gods of ZFS and data should be just fine. Just import and rollback to previous snap (Nothing's lost by that, I was just wiping a cluster of dead files)
2. I managed to wipe the root directory -R as well. Like, the OS itself and my config file. I honestly don't know how it jumped from a data subdir to the root dir. But.... I have config backups anyway.

My last backup config is from maybe 3 weeks ago. But I know a few shares changed slightly since then. Not fatally, but still worth looking for the old config. The old boot volume had no snaps newer than my backup when mounted after reinstall. But it did contain a bunch of mountable .system datasets, and in these are one .db file per day, about the same size as a config file, every 24 hours, right up to a few hours ago. The latest is "20180114%s.db" - barely 6 hours before things died.

I don't want to try without checking, in case it kills anything, so pretty please with cherries on top, in return for the mild entertainment and a chance to let the schadenfreude out to play a bit , could someone confirm if these are what I think they miiiight be, and if so, whether it's safe to rename to "freenas-v1.db" and reinstate the latest of them?

Thanks!

 

[MrToddsFriends]

But it did contain a bunch of mountable .system datasets, and in these are one .db file per day, about the same size as a config file, every 24 hours, right up to a few hours ago. The latest is "20180114%s.db" - barely 6 hours before things died.

There is a hint in the docs: "Saving the configuration after making any configuration changes is highly recommended. FreeNAS® automatically backs up the configuration database to the system dataset every morning at 3:45."
https://doc.freenas.org/11/system.html#general

For comparison (while stuff is mounted into /var/db/system/configs[...] in a running system):

Code:

~ # ls -altr /var/db/system/configs-f36704f2fe794cb6a75657843255655d/ | grep FreeNAS | tail -5
drwxr-xr-x   2 root  wheel  19 Jul 21 03:45 FreeNAS-11.0-U1 (aa82cc58d)
drwxr-xr-x   2 root  wheel  49 Sep  6 03:45 FreeNAS-11.0-U2 (e417d8aa5)
drwxr-xr-x   2 root  wheel  22 Sep 26 03:45 FreeNAS-11.0-U3 (c5dcf4416)
drwxr-xr-x   2 root  wheel  15 Dec 23 03:45 FreeNAS-11.0-U4 (54848d13b)
drwxr-xr-x   2 root  wheel  25 Jan 15 03:45 FreeNAS-11.1-RELEASE (dc7d195f4)
~ # ls -altr /var/db/system/configs-f36704f2fe794cb6a75657843255655d/FreeNAS-11.1-RELEASE\ \(dc7d195f4\)/ | grep db | tail -5
-rw-r-----   1 root  wheel  407552 Jan 11 03:45 20180111%s.db
-rw-r-----   1 root  wheel  407552 Jan 12 03:45 20180112%s.db
-rw-r-----   1 root  wheel  407552 Jan 13 03:45 20180113%s.db
-rw-r-----   1 root  wheel  407552 Jan 14 03:45 20180114%s.db
-rw-r-----   1 root  wheel  407552 Jan 15 03:45 20180115%s.db

So yes, If your .db files are from 3:45 in the morning it is highly likely that you found a set of configuration backups. I don't think that you have to rename anything before importing but I must admit that I didn't have to do that so far.

 

[danb35]

I don't think that you have to rename anything before importing

No, you don't. Just get a copy of the latest one onto one of your client computers, do a fresh install, cancel out of the wizard, and upload that saved config file.

 

[Stilez]

There is a hint in the docs: "Saving the configuration after making any configuration changes is highly recommended. FreeNAS® automatically backs up the configuration database to the system dataset every morning at 3:45."
https://doc.freenas.org/11/system.html#general

So yes, If your .db files are from 3:45 in the morning it is highly likely that you found a set of configuration backups. I don't think that you have to rename anything before importing but I must admit that I didn't have to do that so far.

Thanks! I didn't see that section, but it's conclusive and the latest .db was indeed almost totally up to date. Wouldn't have been huge to lose it, but I was doing some tuning+testing for CIFS improvement and to better use the extra memory I just gave it, earlier yesterday, and didn't have a backup of where I'd got to since I hadn't finished. So this saves any guesswork.

Incidentally - when I restored it, I also added periodic snaps x 7 days to the freenas-boot pool as a task, so it isn't just snapped during an upgrade. Just in case I need a quick rollback for any reason in future. It's low cost and harmless if ever needed.

Thanks a 10^6!!