Today I got the following when trying to restore one of my containers from backup:
[root@lxd1 ~]# lxd recover
This LXD server currently has the following storage pools:
- ee (backend="zfs", source="")
The recovery process will be scanning the following storage pools:
- EXISTING: "ee" (backend="zfs", source="")
Would you like to continue with scanning for lost volumes? (yes/no) [default=yes]: yes
Scanning for unknown volumes...
Error: Failed validation request: Failed checking volumes on pool "ee": Instance "eedtest" in project "default" has snapshot inconsistency: Snapshot count in backup config and storage device are diffe
rent: Backup snapshots mismatch
Which is correct, since I’m not backing up the snapshots, only the main filesystem.
Would it be possible for lxd recover to ignore snapshot inconsistencies and simply not try to restore snapshots in this case? It would save me a lot of manual editing of metadata files, which even if I automate will be terribly fragile as the format is not really guaranteed.
The lxd recover command is for recovering from a database corruption/lost on a system, rather than restoring from backups. The reference to “backup snapshots mismatch” is misleading in this case (it uses the same function CheckInstanceBackupFileSnapshots in both lxd recover and lxc import to check the consistency of the storage to the associated config), and we should probably change this to avoid mentioning “backup” during lxd recover usage.
The position on this is that lxd recover shouldn’t be used for restoring backups, but only as a form of recovery of the local system should something happen to the database.
As such its purpose is to look for inconsistencies between the storage layer and the database and recover them using the instance’s backup.yaml file. So we don’t want to get into a situation where the tool is recovering the DB in such a way that is out of sync with that of the storage layer. If this has occurred for some reason then the storage layer or the instance config backup.yaml files on disk should be fixed so that they align and the recovery can proceed.
We do have a page in our documentation covering LXD’s supported backup methods though:
Ok, fair enough, but in case where you just drop the snapshots that have no underlying filesystem snapshots, there will be no inconsistency created, and you could claim that it recovers not only from the database disasters, but also storage disasters. Win win
