ZFS NVME screwed, zpool dataset error: How to access and safely recover data in nvd0p4 to another device.

Attachments

  • 17315648103526467777041654496753.jpg
    17315648103526467777041654496753.jpg
    1.4 MB · Views: 38
Try to create a directory in /tmp

mkdir /tmp/mnt
Then zpool import -R /tmp/mnt -o readonly=on zroot

I forget that the live usb is readonly, hopefully /tmp is not.
 
monwarez

I have external hard drive at da1 (fat32 with MBR, da1s1)

gpart destroy -F /dev/da1
gpart create -s mbr /dev/da1
gpart add -t fat32 /dev/da1
newfs_msdos -L FILES -F 32 /dev/da1s1

mount_msdosfs -u 1001 /dev/da1 /tmp/mnt1
 
I'm getting cp: crown: *** : invalid argument
That probably has something to do with the differences between ZFS and fat32 concerning allowable characters in a filename, or other file properties like permissions.
If the fs on da1 is going to be a temporary one, you could create a ZFS fs instead of fat32; you'll preserve all ZFS properties. Take into account that you have no redundancy for your data, as is the case for your laptop drive.
 
monwarez

I'm getting cp: chown: *** : invalid argument

#cp -iprv /tmp/mnt/usr/home/my folder/tmp/mnt1/myfiles
That is because FAT does not have any idea of owners and groups.
So this is by design, if you need to preserve these information you need to tar the data together.
 
That is because FAT does not have any idea of owners and groups.
So this is by design, if you need to preserve these information you need to tar the data together.
Crivens
be that case it may, how can one manage to get around "readonly" corrupted ssd drive and accomplish what you are suggesting.

+concisely put as your reply was, surely you've got something.
 
There is no getting around a readonly drive. You need to copy the data off it to some other media. You can't use zfs send because you can't create a snapshot so you will need to do dd, see below.

As it's a zpool, the first thing I'd try is boot FreeBSD from a large USB. Large in the sense that there's a small partition just containing FreeBSD + a few utilities from ports (ddrescue and dd_rescue). The rest of the USB would be empty. Now create a partition of the exact same size as the dead SSD's zpool. dd it using dd, ddrescue, or dd_rescue to the newly created partition on the USB. Try dd first. If it fails ddrescue and dd_rescue will try to ignore errors, resulting in a corrupted target pool. But a corrupted target pool is better than no pool.

This will only work if you know what you're doing and avoid mistakes. Any mistakes and you're in the perpetual catch up and recover from mistakes rabbit hole.

Personally, I maintain a bootable USB disk. It's used when recovering from serious problems, like this, plus it's used to restore from backups, allowing me to recreate any of my machines from backup. I also used it to copy my UFS system partitions (/, /usr, /var) and my zpool from my old legacy BIOS MBR laptop to my new UEFI GPT laptop, creating the necessary EFI partiton and copying the data from the old laptop's SSD to the current laptop's NVME SSD. A Swiss Army Knife bootable USB. You need a smidgen of this.

As you don't have such a setup, if you want to recover your data you will need to install FreeBSD on a USB disk or SSD, large enough for the above. Be patient. This will take some time and effort.
 
Crivens
be that case it may, how can one manage to get around "readonly" corrupted ssd drive and accomplish what you are suggesting.

+concisely put as your reply was, surely you've got something.
cd /media/where/target/is
tar zcf - /tmp/where/source/is | split -b 1500M

This is from memory, so you should read the man pages. This will give you a set of xaa xab xac ... files which are all 1.5GB in size so FAT32 will bit choke on them. For extraction you can cat them back into tar.
 
cd /media/where/target/is
tar zcf - /tmp/where/source/is | split -b 1500M

This only works if one has not altered the mountpoint property for any datasets. i.e.

Code:
cwsys# zfs list cwsys/export
NAME           USED  AVAIL  REFER  MOUNTPOINT
cwsys/export  90.8G   224G  4.28G  /export
cwsys# 
cwsys# zfs get mountpoint cwsys/export
NAME          PROPERTY    VALUE       SOURCE
cwsys/export  mountpoint  /export     received
cwsys#

And legacy mounts in fstab:

Code:
cwsys/var/mail                  /var/mail       zfs     rw 0 0

Otherwise you'll only tar the datasets mounted under the zpool's mountpoint.
 
Otherwise you'll only tar the datasets mounted under the zpool's mountpoint.
My assumption was that the pool was imported under a new root directory. Also, all of that was "from memory", so reading up on the man pages is strongly advised.
 
My assumption was that the pool was imported under a new root directory. Also, all of that was "from memory", so reading up on the man pages is strongly advised.
Even imported under a new directory, mountpoint properties are still honoured. This won't work without the extra effort of copying those mountpoints separately. The point is this will be painstakingly slow and detailed work.
 
Personally, I maintain a bootable USB disk. It's used when recovering from serious problems, like this, plus it's used to restore from backups, allowing me to recreate any of my machines from backup. I also used it to copy my UFS system partitions (/, /usr, /var) and my zpool from my old legacy BIOS MBR laptop to my new UEFI GPT laptop, creating the necessary EFI partiton and copying the data from the old laptop's SSD to the current laptop's NVME SSD. A Swiss Army Knife bootable USB. You need a smidgen of this.
I found lots of how-tos for making a Linux-based, swiss army knife, bootable USB stick. Can you point me to a how-to for doing so with FreeBSD, please? Thank you.
 
I found lots of how-tos for making a Linux-based, swiss army knife, bootable USB stick. Can you point me to a how-to for doing so with FreeBSD, please? Thank you.
There is no how-to that I know of. I've been working with computers for ~50 years (19 with mainframe, 31+ with UNIX). I cobbled up a disk myself.

I used to build rescue systems for Solaris. Same concept. At $JOB we have a rescue VM. We put the VM into a VLAN, PXE boot the affected system and repair. One could also do this with FreeBSD. My network at home isn't that big so, a rescue USB is just fine.

What you need to do is install onto a USB instead of an internal disk, or clone your FreeBSD O/S (I did this). Then, install some ports. Keep the rest of the USB disk "empty." I maintain backups on the remainder of the disk; in the worst case I can use it to restore my laptop or servers downstairs (using an additional disk for backups).

The other thing I do is on my servers downstairs & previous laptop (haven't set this up on my current laptop yet), is install FreeBSD on a second partition. Should the first partition fail to boot, simply boot the second partition. Data and /usr/local is in a third partition (ZFS). I can use the base system and the tools on the third partition to rescue the primary partition.

As a developer there are times something I'm working on results in an unbootable system. I've learned over the years to have many layers of belt and suspenders to avoid getting into a pickle.

There is no how-to for FreeBSD. Someone needs to write it. I would except I have way too much other FreeBSD work on my plate.
 
There is no how-to that I know of. I've been working with computers for ~50 years (19 with mainframe, 31+ with UNIX). I cobbled up a disk myself.

What you need to do is install onto a USB instead of an internal disk, or clone your FreeBSD O/S (I did this). Then, install some ports. Keep the rest of the USB disk "empty." I maintain backups on the remainder of the disk; in the worst case I can use it to restore my laptop or servers downstairs (using an additional disk for backups).

There is no how-to for FreeBSD. Someone needs to write it. I would except I have way too much other FreeBSD work on my plate.
Thank you and understood. The second paragraph may point the way!
 
Back
Top