Making externally created zfs snapshots known to lxc?

is there any way to make an externally created zfs snapshot (e.g. with sanoid or znapzend or manually) visible in lxc info or available to lxc copy etc?

I’d like to use a bit more sofisticated snapshotting policy than currently possible through snapshots.schedule, but it would be nice to still have them easily accessible through the API/lxc cmdline.

1 Like

Not easily, you’d need to inject the matching DB records for the volume snapshot, the instance snapshot and a copy of all the instance config and devices at the time of the snapshot.

Could you use your custom snapshot policy to execute lxc snapshot <instance> <snapshot name> when needed with the chosen snapshot name, rather than take the storage snapshots directly?

I could, of course, but that woud mean I have to write everything from scratch and not reuse already debugged solutions. But I guess I will have to, I thought adding a snapshot was just a line in a database but wasn’t thinking that the config also needs to be stored, which makes “registering” snapshots independently of making them not really terribly robust, as I would have to guess what the config was at the time.

What I need is nothing terribly complicated, I just want a standard backup setup: keep x dailies, y weeklies, z monthlies and so on. Maybe extending snapshot.schedule to include a pattern and expiry per schedule would suffice for most people, I already see that I’m not the only one, see for example: Snapshots.schedule

I am interested in this capability as well, particularly integration with sanoid/syncoid. The use cases for this functionality are as follows:

  • Backup Retention: you may want to keep a variety of snapshots going back several months (or even years) but you need a variable level of granuarlity as you go farther back in time (or storage space and the sheer number of snapshots will become unmanagable). For example, let’s say you take snapshots every hour. You may want a lot of granularity in recent snapshots, say the last 10 hourly snapshots, but then you only need 2 snapshots from last week, 1 snapshot from last month, and 1 from last year. Sanoid lets you configure this type of variable-granularity-based-on-timescale and it would be great if we could do this with LXD too

  • Warm Spare: it’s desirable to maintain a warm spare server with a copy of the LXD container data: in case the active server goes down, the LXD container can quickly be brought back online on the warm spare. This is discussed briefly here, but utilizing syncoid and ZFS snapshots to only send the updated delta means that keeping the warm spare up-to-date is easy and doesn’t require re-syncing the whole container. I think you could do this now with syncoid and its --no-sync-snap flag, but again you’d end up accumulating a very large number of old snapshots on the warm spare server with no good way to prune them. Yes, this would require using lxd recover to bring the container online on the warm spare, but I think that is okay for this type of scenario?

Moreover, it seems like lxc copy is limited in what it can currently due in the above scenarios since the container must be off and if the destination container already exists, it throws an error (rather than just syncing the delta update):

lxc copy --verbose myinstance myremote:myinstance
Error: Failed instance creation: Failed creating instance record: Add instance info to the database: This "instances" entry already exists

UPDATE: This is true for the latest LTS release (5.0) but I see that newer releases added the --refresh flag and appear to be able to copy from a running instance.

Sanoid now supports pre-snapshot, post-snapshot, and post-prune hooks so if LXD had a command like lxc snapshot --metadata-only --snapshot-name="xxx" to only create/delete/update the database entry but not actually try to zfs snapshot/zfs destroy the snapshot, this would work I think (you could let sanoid be in charge of creating and deleting the snapshots).

Is it possible to add the above type of enhanced functionality for snapshots to LXD, or provide some type of integration with 3rd-party tools like sanoid/syncoid?

1 Like

Bump - any thoughts on this functionality?

1 Like

FWIW, I’ve now been successfully using lxd-snapper for months to make and maintain custom interval snapshots. Still using syncoid for backup though, but one day I’ll upgrade my backup server to something that can run lxd and then use lxc copy --refresh for backup

Nice, that does seem like it could integrate well with syncoid since it looks like lxd-snapper lets you customize the snapshot name format, so you could most likely make the snapshots look like sanoid-style snapshots. This looks good, but it would still be best if LXD could natively support this functionality too.