Proxmox - Auto snap

G

Giggling3999

Member
Apr 2, 2024
86
5
8
Hi

I've recently moved ZFS pools over to Proxmox, and this is causing me a few issues

I have a tool zfs-auto-snapshot installed - This has been a real life saver in the past, as I have it snapping every 15 minutes etc.. I would very much like to keep it

This does however present a few problems with backups and inbuilt snapshots using the proxmox gui.

1. When doing a manual snapshot - I am unable to rollback to it, due to snapshots being in between. The auto - snaps also do not show up in the manual snapshots list
2. LXC containers have a directory /.zfs/ - Which contains the snapshots. This has been potentially useful! however - It causes issues when trying to do a backup/restoration....I get permission/symbolic link errors (Too many levels)


Is there any clever ways of getting these things to work nicely together?

Thanks in advance
 
oh - + Syncoid. Here's a restoration error(s)

Code: 
tar: ./.zfs/snapshot/mypc-sys_2025-04-17\:09\:44\:49-GMT01\:00: Cannot mkdir: Permission denied
tar: ./.zfs/snapshot/zfs-auto-snap_hourly-2025-04-17-0217: Cannot mkdir: Permission denied
 
  • Like
Reactions: news
Looks like they have retention ?

Presumably you have this running from some sort of LXC container?

Oh no! Swapping tools!
 
Giggling3999 said:
Looks like they have retention ?
Click to expand...
Yes.

I do run every 15 minutes and keep 4 of these. And I do run another one once in the early morning and keep two of these.

Older "snapshots" are stored on the PBS ;-)

While I could keep a lot more snapshots it is really painful to rollback to an older one. I was not able to find an easy way to do this. To remove dozens of newer snapshots than the one I want to rollback to is a drama. :-(

(Yes, I could write a script, but...)

Giggling3999 said:
Presumably you have this running from some sort of LXC container?
Click to expand...
I've installed it directly on one node as the configuration is cluster-wide. And it runs directly as root - which is possibly bad style.
 
  • Like
Reactions: news and Johannes S
Hm - Looks like it has some positives. Some negatives too

Does it fix the backup issues? When backing up does it ignore these?

Often - I usually just copy what I want restored from /.zfs/snapshot.... It's a bit easier - The rollback thing is a pain
 
I use auto-snap-shot on only some zfs datasets.
i set zfs set com.sun:auto-snapshot=[false|true] <zfs-datapool> to true if i want zfs auto snapshots.

The root dataset, has set rpool as zfs set com.sun:auto-snapshot=false rpool

I use tools from github bashclub from sysops tv, this is a provider in Germany.

$ checkzfs --sourceonly
 
Last edited:
  • Like
Reactions: UdoB
You can tell ZFS to hide the.../.zfs folder, but you can still access it, if you know that it's there. That might help with your backup problem. Try zfs set snapdir=hidden <dataset>
 
Giggling3999 said:
Often - I usually just copy what I want restored from /.zfs/snapshot.... It's a bit easier - The rollback thing is a pain
Click to expand...
".zfs/snapshot/" does exist for cv4pve too. And yes.

(For datasets; not for zvol of course.)

Not mentioned yet: it uses the PVE API. This means that "the VM" is actively informed that a snapshot is going to happen - and it gets a chance to prepare itself for this. In my understanding this is much cleaner than "just" snapshotting a mounted blockdevice or a busy filesystem. At least as long as the qemu-agent is active...
 
  • Like
Reactions: Johannes S
zodiac said:
You can tell ZFS to hide the.../.zfs folder, but you can still access it, if you know that it's there. That might help with your backup problem. Try zfs set snapdir=hidden <dataset>
Click to expand...
I'm going to try this

I can still access like you say but hopefully it fixes the backup....Weirdly I can't replicate the error, this morning

I guess the rollback issue is still an issue regardless of which snapping tool is used, so better to get the backup in place
 
You must log in or register to reply here.
Top Bottom