My TrueNAS setup has /mnt/data, and backs up nightly to /mnt/onsite-backup, and manually to /mnt/offsite-backup
This morning, I attempted to restore a dataset off one of the backup drives, and accidentally targeted /mnt/data erasing everything there.
Now I’m trying to replicate /mnt/onsite-backup back onto /mnt/data, but everything I am trying is failing. I know I’m exasperated at the moment, but trying to just restore a backup should not be this hard.
Is there an easy way to clone one of the backup pools onto /mnt/data, completely and seamlessly? It seems like each time I try, something is blocking the process, such as “broken pipe”. Even restoring the individual datasets is failing.
Edit for more information; TrueNAS SCALE, Fangtooth
1 Like
OK, I am able to restore some of the individual datasets, one at a time. I’ll be doing this over the course of the day as each one completes. If anyone has insight on restoring any special / tricky sets, like ./ix-apps please let me know, and i’ll save them for last.
1 Like
As I am copying my datasets back, they are coming back Read-Only.
Is there a way to recursively apply zfs set readonly=off (dataset) to a dataset, so it also propagates through all of the subsets, too?
Add an -r flag after set.
The confusion arises with restores due to how ZFS treats the pool’s top-level root dataset. Some people conflate it with the “pool”.
This is why I personally create “pseudo roots”, which makes replications, backups, and restores more intuitive.
Pseudo root datasets are glorified placeholders. Think of them as keychains for your keys.
1 Like
The keychain analogy / idea is a good one, thank you. I’ll have to implement that down the line a bit.
Unfortunately, it looks like -r doesn’t work with zfs set - I did some additional digging, and found a workaround:
zfs set readonly=off $(zfs list -t filesystem -H -o name -r data/apps)
Where “data/apps” is my Pool and the parent dataset.
1 Like
