Recover FreeNas Configuration From OS Drive

[BlazeStar]

It'd be better to do it from another FreeNAS image. Looks like the partition's there though. A "df /dev/da5s4" would be interesting too, see if it's vaguely readable.

Sorry for late reply !

here goes:

Code:

[root@NAS] /var/tmp# fdisk da5
******* Working on device /dev/da5 *******
parameters extracted from in-core disklabel are:
cylinders=487 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=487 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 1930257 (942 Meg), flag 80 (active)
    beg: cyl 0/ head 1/ sector 1;
    end: cyl 890/ head 15/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 1930383, size 1930257 (942 Meg), flag 0
    beg: cyl 891/ head 1/ sector 1;
    end: cyl 757/ head 15/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3860640, size 3024 (1 Meg), flag 0
    beg: cyl 758/ head 0/ sector 1;
    end: cyl 760/ head 15/ sector 63
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3863664, size 41328 (20 Meg), flag 0
    beg: cyl 761/ head 0/ sector 1;
    end: cyl 801/ head 15/ sector 63

And for the df:

Code:

[root@NAS] /var/tmp# df /dev/da5
df: /dev/da5: Invalid argument
[root@NAS] /var/tmp# df /dev/da5s4
df: /dev/da5s4: Invalid argument

 

[jgreco]

That looks very much like something rotted the flash that holds the metadata for s4. Recoverability chances decrease.

Try:

# fsck_ffs -b 32 -B -f -n /dev/da5s4

It will not write data to your USB drive (that's the "-n") but it'll give us some idea about the state. UFS stores an alternate superblock out at block 32, so even if the primary is trashed, we might be able to figure out how to get it to cough up something.

Or we could try to work through a different route, using "dump" to extract whatever is easily findable out there:

# dump 0sf 99999 /tmp/backup.dmp /dev/da5s4

Also should not be destructive, and if it works, then we see if we can retrieve things out of /tmp/backup.dmp

If neither of those work, it's beyond the help you're going to get on a forum (sorry).

 

[BlazeStar]

That looks very much like something rotted the flash that holds the metadata for s4. Recoverability chances decrease.

Try:

# fsck_ffs -b 32 -B -f -n /dev/da5s4

It will not write data to your USB drive (that's the "-n") but it'll give us some idea about the state. UFS stores an alternate superblock out at block 32, so even if the primary is trashed, we might be able to figure out how to get it to cough up something.

Or we could try to work through a different route, using "dump" to extract whatever is easily findable out there:

# dump 0sf 99999 /tmp/backup.dmp /dev/da5s4

Also should not be destructive, and if it works, then we see if we can retrieve things out of /tmp/backup.dmp

If neither of those work, it's beyond the help you're going to get on a forum (sorry).

Thanks so much for taking the time!

Here goes:

Code:

[root@NAS] ~# fsck_ffs -b 32 -B -f -n /dev/da5s4
Alternate super block location: 32
NOT MOUNTED, CANNOT RUN IN BACKGROUND
** /dev/da5s4 (NO WRITE)
32 is not a file system superblock

and

Code:

[root@NAS] ~# dump 0sf 99999 /tmp/backup.dmp /dev/da5s4
  DUMP: Date of this level 0 dump: Mon Mar 23 16:40:47 2015
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da5s4 to /tmp/backup.dmp
  DUMP: Cannot find file system superblock
  DUMP: The ENTIRE dump is aborted.

 

[jgreco]

That's pretty hosed, then. Sorry. :-/ Guessing a block of flash just decided to give it up.

 

[BlazeStar]

That's pretty hosed, then. Sorry. :-/ Guessing a block of flash just decided to give it up.

So are you saying there's absolutely nothing to be done?

If there are any agressive data recovery process that could make my USB key explode, I don't mind ;)

If not, I'll just have to redo my config from scratch :S

 

[jgreco]

Probably nothing that's worth the time and effort. It is certainly possible to go scanning for inodes and then try to recover files on that basis, but the right tools aren't there on a FreeNAS box.

 

[BlazeStar]

Probably nothing that's worth the time and effort. It is certainly possible to go scanning for inodes and then try to recover files on that basis, but the right tools aren't there on a FreeNAS box.

Alright thank you very much for the time you spent on this!

I'll probably upgrade to 9.3 soon as I've seen that the new installer provides the option to select multiple devices, meaning that you can now mirror the boot device...

Hoping this will never happen again ;)

 

[jgreco]

Also be sure to grab one of the several scripts posted that periodically save your configuration to the pool. Belt AND suspenders is better than just one or the other.

 

[jkh]

Also be sure to grab one of the several scripts posted that periodically save your configuration to the pool. Belt AND suspenders is better than just one or the other.

Though it should also be pointed out that FreeNAS 9.3 already creates a database backup to the pool every time you change the database (e.g. on every configuration change).

See the /var/db/system directory (this is actually on your system dataset, as "zfs mount" will show).

 

[jgreco]

Though it should also be pointed out that FreeNAS 9.3 already creates a database backup to the pool every time you change the database (e.g. on every configuration change).

See the /var/db/system directory (this is actually on your system dataset, as "zfs mount" will show).

I did notice that but I was too lazy to figure out what the size of the history was. Our script is simplistic and offers a long history.

https://forums.freenas.org/index.ph...-freenas-configuration-database-backup.10735/

 

[BlazeStar]

Though it should also be pointed out that FreeNAS 9.3 already creates a database backup to the pool every time you change the database (e.g. on every configuration change).

See the /var/db/system directory (this is actually on your system dataset, as "zfs mount" will show).

I only have one volume and I'm replicating it.

Does this mean I'm also replicating a backup of my config? Because that'd be awesome.

 

[jgreco]

I'm guessing not. It's part of the pool, but a separate dataset.