Learn MicroCloud - Snapshots, Backups & Restore

#Introduction

In episode 9 your cloud proved resilient against dead nodes. But HA doesn't protect against human error: deleted files, failed updates, or broken configurations. In episode 10 we build a data safety net — snapshots for fast recovery, and backups for recovery from larger disasters.

An analogy: a snapshot is an instant photo of a room — quick to take, quick to restore, but it's in the same building. A backup is an archive elsewhere — slower, but it survives even if the building burns down. A responsible cloud needs both.

#Instance Snapshots

#Basic Snapshots

A snapshot captures an instance's state (disk + config) at a point in time:

Create an instance snapshot

lxc snapshot c1 snap1

View the snapshot list

lxc info c1
lxc list c1

#Restoring a Snapshot

To return an instance to the state when the snapshot was taken:

Restore to a snapshot

lxc restore c1 snap1

Delete a snapshot

lxc delete c1/snap1

Note

Restore overwrites the instance's current state with the snapshot's contents. Since the instance volume lives on Ceph, the snapshot and restore also happen at the RBD layer — LXD is just the interface. For VMs, make sure the instance is stopped before restoring if you want a deterministic result.

#Scheduled Snapshots

A good practice: automatic snapshots with snapshots.schedule on an instance or profile:

Enable daily snapshots

lxc config set c1 snapshots.schedule "0 2 * * *"
lxc config set c1 snapshots.expiry 7d

The instance is now snapshotted every day at 02:00, and snapshots older than 7 days are cleaned up automatically.

#Storage Pool Snapshots and Ceph RBD

#Pool Snapshots

LXD also supports snapshots at the storage volume and pool level — useful before big operations:

Snapshot a Ceph pool volume

lxc storage volume snapshot remote c1 pre-update

#RBD Snapshots in Ceph

Behind the scenes, an LXD volume snapshot on the Ceph pool is an RBD snapshot. You can view and manage them directly from the Ceph side:

View RBD snapshots

rbd snap ls lxc/c1

The LXD + Ceph combination means snapshots are created efficiently at the block layer, without copying the whole dataset (copy-on-write) — fast and space-efficient. This is the power of snapshots on distributed storage.

#Backups: Export and Import

#Exporting an Instance to a File

Snapshots live in the same cluster. To protect against losing the entire cluster, export instances to a portable file:

Export an instance to a file

lxc export c1 /backup/c1-backup.tar.gz

This file contains the config, disk, and (optionally) snapshots. To back up along with all snapshots:

Export with snapshots

lxc export c1 /backup/c1-full.tar.gz --instance-only=false

#Importing to a Cluster

To restore an instance from a backup file:

Import from a file

lxc import /backup/c1-backup.tar.gz

Import with a new name

lxc import /backup/c1-backup.tar.gz --name c1-restored

Tip

Store export files outside the cluster — object storage, NFS, or a separate machine. Files stored on the cluster's own disks will be lost along with the cluster. lxc export is your gateway to off-site backups.

#Backup Integrations: Restic and PBS

#Restic Inside a VM

For application backups (files, database dumps), run a backup agent inside the instance. restic is a popular choice: deduplicating, encrypted, and supporting many repositories:

Install restic inside a container/VM

lxc exec c1 -- apt install -y restic

Init a repository and back up

lxc exec c1 -- restic -r s3:https://... init
lxc exec c1 -- restic -r s3:https://... backup /var/www

restic backs up from within, at the application level — complementary to LXD snapshots that capture the entire instance.

#Proxmox Backup Server (PBS) in a VM

For efficient block-level backups (dedup, incremental forever), you can run Proxmox Backup Server as a VM inside MicroCloud itself, then back up other instances to PBS:

Create the PBS VM

lxc launch ubuntu:24.04 pbs --vm --profile default --profile big

On the client side, other instances (or hosts) can back up with proxmox-backup-client. This "cloud inside a cloud" combination is popular for homelabs: MicroCloud data is backed up to PBS, which also runs on MicroCloud — but ideally PBS still lives on a separate machine/network for a real disaster recovery scenario.

#Recommended Backup Strategy

Consider these layers:

Daily LXD snapshots (e.g., snapshots.schedule): fast recovery from small mistakes, 7-day retention.
Manual RBD/Ceph snapshots before big upgrades: reliable point-in-time rollback.
Weekly lxc export to off-cluster storage: instance recovery on a new cluster.
Application backups (restic/PBS) inside instances: protects data living in application databases, not just disks.

#Common Pitfalls

Snapshots aren't backups: snapshots live in the same Ceph cluster — delete the cluster and the snapshots are gone too. Always have an external export/backup layer.
Restoring a running VM: the result can be inconsistent; stop the VM first.
Export without --instance-only=false: snapshots aren't included — check the flag as needed.
Forgetting snapshot retention: a Ceph pool can fill up from accumulating snapshots; set snapshots.expiry.

#Closing

Key takeaways:

lxc snapshot gives fast recovery; schedule it with snapshots.schedule and bound it with snapshots.expiry.
Volume snapshots on the Ceph pool are RBD snapshots — efficient via copy-on-write.
lxc export/import moves instances to a portable file; store it outside the cluster.
Application backups with restic/PBS protect logical data, not just disks.
A layered strategy: fast snapshots + periodic exports + application backups.

In the next episode, we'll cover scaling: adding nodes & disks — adding new members with microcloud join, automatic Ceph rebalancing, adding OSDs with microceph disk add, and expanding storage pools. Your cloud is starting to grow!