a bad OS drive, by reinstalling its OS to another drive (a USB-attached SATA SSD this time), and deployed it into an initial state, according to internal documentation. If desired, you can read more about the previous stages of this recovery here. Now I'm at a stage where I really need some files from that original USB stick, but feel aversed to plugging in that USB stick. Its btrfs filesystem has already failed after all. I don't even know if mounting it read-only could further damage the flash inside, if that's where the issue is. That said though, those files are critical and their locations have been identified. Maybe I could do a quick in-out and pull just those files, without requesting any reads to elsewhere in the filesystem. This means that I'll have to go as simple as possible. No fancy mount helpers, command-line mount(8) only. Using this, read-only could be passed as an option. But still.. file managers and terminals would want to read directory contents on every navigational step into that filesystem. Can / should that be reduced further?
Where are your backups man?
ZFS users don't believe in backups... ZFS magic sorts it out for them
pretty much, zfs snapshots+replication are awesome, but that wouldn't respect the 2 in 321, so still necessary
my favourite is when it's ZFS on a single physical drive
I did back up the storage for the LXC containers. Snapshots and send/receive make that fairly easy to do. But LXC stores the container config outside the ZFS subvolume. That's what I didn't back up.
Yeah I would have kept configs in git or just periodic rsync.
Обсуждают сегодня