Learn LXC - Snapshot & Clone

#Introduction

In episode 8 we saw lxc-snapshot and lxc-copy at a glance. Now we'll break down both completely — because these are the skills that save you from sleepless nights after a system-breaking update. Snapshots for going backward (rollback), clones for going forward (scale out). In episode 9 we master both along with their backend trade-offs.

#Snapshots with lxc-snapshot

#Concept

A snapshot is a recording of a container's state at a point in time: rootfs, config, and (on certain backends) process state. Use it before risky changes — big package updates, config changes, or experiments — so you always have a safe point to return to.

#Taking a Snapshot

Take a snapshot of c1

lxc-snapshot -n c1

Its behavior depends on the backend:

dir: the snapshot is a full copy of the rootfs — safe, but needs as much disk space as the container.
btrfs/zfs: the snapshot uses the filesystem's native mechanism — nearly instant and disk-efficient thanks to copy-on-write. This is the most efficient for routine snapshots.

#Listing Snapshots

List c1 snapshots

lxc-snapshot -n c1 -L

The output shows a list of snapshots with index, creation date, and name if given:

#Restoring and Running a Snapshot

To restore the container to a snapshot's state:

Restore to snapshot snap1

lxc-snapshot -n c1 -r snap1

Each snapshot can also be run as its own container for inspection (snapshots are auto-populated in /var/lib/lxc/c1/snaps/):

Run a snapshot as an inspection container

lxc-start -n c1/snap1
lxc-attach -n c1/snap1 -- ls /
lxc-stop -n c1/snap1

Warning

Restore overwrites the container's current state. Make sure the snapshot you're restoring to is really the one you want — and for safe work, first copy the container to a new name with lxc-copy before experimenting with restore.

#Cloning with lxc-copy

#Full Copy

Full copy c1 into c2

lxc-copy -n c1 -N c2

A full copy creates a completely independent rootfs copy: changes in c2 don't affect c1, and vice versa. The cost: copy time and full disk space. Choose this when both containers will coexist long-term with different contents.

#Snapshot Clone (Overlay)

Snapshot clone c1 into c3

lxc-copy -n c1 -N c3 -s

The -s flag creates a snapshot clone: c3 shares data with c1 via the backend's copy-on-write mechanism. The process is nearly instant, and the disk used is only for the differences between the two. It's perfect for:

Creating many working instances from one "golden image".
Test environments that get discarded after use.
Booting containers in seconds from a single base.

Tip

Choosing rule: need full independence and have spare disk? Full copy. Need fast duplication, disk savings, and a shared base? Snapshot clone (-s). Remember, a snapshot clone depends on its source — if the source is deleted, don't delete it before the clone is no longer in use.

#Best Practices

#Safe Snapshot Workflow

Container in a stable state → lxc-snapshot -n c1 (safe point).
Perform the risky change (update, config).
If broken → lxc-snapshot -n c1 -r <snap> to go back.
If successful → take a new snapshot as the next safe point.

#Golden Image Cloning

Prepare a master container with all standard tooling and config.
lxc-stop -n master.
lxc-copy -n master -N node1 -s (and node2, node3...).
Each node starts and runs with an identical base.

Example golden image pipeline

lxc-snapshot -n master
lxc-copy -n master -N web-1 -s
lxc-copy -n master -N web-2 -s
lxc-start -n web-1
lxc-start -n web-2

Note

Snapshots and clones involving runtime state (e.g. a database that's actively writing) should be done while the container is stopped or in a consistent state — otherwise the snapshot might capture files that are half-written. For critical data, combine with filesystem backups rather than relying only on snapshots.

#Verifying the Results

Make sure the clone is truly separate:

Verify the cloned containers

lxc-ls -f
lxc-attach -n web-1 -- hostname

Change the hostname in web-1, then check that master doesn't change along with it — proof the isolation works.

#Closing

Key takeaways:

lxc-snapshot -n c1 records a state; -L lists them; -r restores.
Snapshots are most efficient with the btrfs/zfs backends (native copy-on-write).
lxc-copy -n c1 -N c2 = independent full copy; -s = disk-efficient snapshot clone.
Snapshots for rollback; clones for scaling out from a single base.
Stop the container before snapshotting anything involving runtime state.

In the next episode 10 we'll cover autostart, systemd & service management — lxc.start.auto = 1 in the config, the lxc@.service systemd unit, the lxc-autostart command, running init/systemd inside containers, plus lxc-stop and lxc-shutdown for orderly shutdown.