Ubuntu 26.04 Tutorial / Restore Snapshots and Clone a VM Safely

A snapshot returns a VM to a saved state and is not an independent backup. Cloning creates another VM, but does not guarantee fresh guest accounts, SSH host keys, or machine identifiers.

Identify data that must survive restoration

Files and settings created after a snapshot may disappear when it is restored. Host shared folders, external databases, and network storage are outside the guest snapshot’s ordinary scope. Copy required work and logs outside the VM and open the copies before restoring.

For the first exercise, shut down the VM cleanly before creating a baseline snapshot. A running snapshot that includes memory differs from a powered-off disk baseline. Use a meaningful name such as clean-install and record the date, verified state, and purpose.

Test restoration with a disposable file

1. Shut down cleanly and create a baseline through VirtualBox’s snapshot view.
2. Boot and create the practice file below outside any important source directory.
3. Shut down again and restore the baseline. Review whether to save the current state separately before replacing it.
4. After boot, check the practice file, login, addresses, and required services.

mkdir -p "$HOME/snapshot-lab"
printf 'after-snapshot\n' > "$HOME/snapshot-lab/marker.txt"
cat "$HOME/snapshot-lab/marker.txt"

If the file did not exist at the baseline, its absence after restoration is expected. If it remains, check for a shared folder or a snapshot taken after creation. This small test does not establish that important application data can be recovered.

The VirtualBox VM management guide explains snapshots, cloning, and export scope.

Boot a clone in isolation first

Before connecting the original and clone together, disable the clone’s network or use an isolated lab segment. Static IPs, hostnames, DHCP identifiers, and shared paths can collide. Check the option to generate new virtual NIC MAC addresses.

hostnamectl
ip -br address
cat /etc/machine-id
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare these values after cloning. Duplicate machine IDs or SSH host keys may not prevent boot, but they undermine independent machine identity. Keep internal identifiers and addresses out of public records. Do not delete keys on the original or apply clone-specific resets to both machines.

Distinguish a lab clone from a deployment template

A one-off comparison may use an isolated clone with distinct addresses and hostname. Deploying an independent server requires a separate plan for SSH host keys, machine-id, cloud-init state, account secrets, and static networking. Blindly deleting one file is not a universal template-preparation procedure.

After restoration or cloning, check time, login, networking, mounts, and service responses. Test importing and booting an independently stored VM backup as a separate exercise. Do not arbitrarily move or delete individual files in a snapshot disk chain.