Using CERMM
Backups
Devices → Backups shows which machines are backed up, which aren't, and which have failed. Two kinds work side by side: Proxmox VE's own backups of whole guests, and file backups of any machine with restic.
New. Backups were built on 2026-11-12. They haven't been run against a real Proxmox VE node, a real Proxmox Backup Server or real restic yet. Try a restore before you trust it. Tell us if something reads wrong.
Which kind to use
| You have | Use |
|---|---|
| Proxmox VE guests (VMs and LXC) | Proxmox backups (vzdump) to Proxmox Backup Server, a NAS share or local storage. Restores a whole guest. |
| Physical machines, laptops, Windows PCs | File backups (restic) to a NAS, Backblaze B2 or S3. |
| A guest whose files you also want off-site | Both: vzdump for the whole guest, restic for the folders that matter, to B2. |
The Backups page
Every machine with its last good backup, how it's backed up, and why it needs you if it does. The pills are Needs attention, Not backed up, File backups, Proxmox and All. Below that: your plans, your destinations, each Proxmox node, each Proxmox Backup Server, and the recent runs.
A device's own page has a Backups section too: its plans, snapshots, Back up now and Restore…. A Proxmox guest's menu has Backups (n)….
File backups (restic)
Each machine's agent runs restic itself, so the data goes straight from the machine to the destination, never through CERMM. Backups are encrypted, deduplicated and compressed. Each machine gets its own repository, a folder named after its device ID under the destination's folder, with its own encryption password. Root on one machine can't open another machine's backups. One backup runs at a time on each machine.
The first backup puts restic 0.19.1 on the machine, downloaded from restic's GitHub releases and checked against its SHA-256 before it runs. If that download fails, the system's own restic package is used. Linux, macOS and Windows are all supported. On macOS, use a REST server, B2 or S3 rather than an SMB share.
1. Add a destination
Backups → Destinations → Add a destination:
| Kind | What it needs | Notes |
|---|---|---|
| NAS share (SMB) | The share (//nas/backups), a folder in it, a username, a password, optionally a domain | Synology, QNAP, TrueNAS, Windows. Linux mounts it with cifs (installed if missing), so unprivileged containers can't use it. Use a REST server for those. |
| REST server | The address (https://nas:8000), a username and password if set | restic's own rest-server, on a NAS in Docker or on any machine. Fast, and works from containers. |
| Backblaze B2 | The endpoint (s3.us-west-004.backblazeb2.com), the bucket, an application key's keyID and applicationKey | Uses B2's S3-compatible API. Make a key that can only reach that bucket. |
| S3-compatible | The endpoint, the bucket, the region if it needs one, an access key and secret key | MinIO on a NAS, Wasabi, Cloudflare R2, AWS S3. |
| Folder | A path for Linux and macOS and one for Windows | A USB disk, or an NFS share that's already mounted. |
Limit what a machine can do. Every machine in a plan gets the destination's login while it backs up. Root on any one of them could delete what's there. Use a key or login for backups only: a B2 application key limited to its bucket (and a namePrefix), an S3 policy for its bucket, or rest-server --private-repos with a login per machine. For backups nobody can delete, use B2 or S3 object lock, or rest-server --append-only.
Save the encryption passwords. A destination has a password, which CERMM makes if you leave it blank and which can't be changed later. Each machine's repository gets its own password, made from that one. Without it nobody can read the backups, CERMM included. If the CERMM server is lost, the backups are useless unless the password is kept somewhere else. Encryption passwords… on the destination shows the destination's password and every machine's (you'll be asked for your password, and it goes in the audit log). Copy them into your password manager, or into CERMM's Passwords. Also back up CERMM's data folder.
2. Make a plan
Backups → New plan:
- Machines: servers, workstations, all, a group or a tag, or picked ones (Pick). A machine joining the group is backed up from its next run.
- Where: the destination.
- When: daily or weekly at an hour of the server's clock. A machine that was off is backed up when it's next online.
- Folders: one list for Linux and macOS (
/etc,/home,/root,/srv,/opt,/usr/local,/var/www,/Users… to start; missing ones are skipped) and one for Windows (C:\Users). On Windows the backup reads from a shadow copy, so open files are fine. - What to skip, upload limit…: patterns to leave out (caches, temp files,
node_modulesto start; any folder with aCACHEDIR.TAGis always skipped) and an upload limit in KiB/s, for a slow line to B2. - Keep: how many snapshots to keep: the last few, then daily, weekly, monthly, yearly. Older ones are forgotten and their space freed after each backup. The repository is checked once a week.
A plan runs as whoever made it, so they must still be able to sign in and run commands. Changes to a plan need Run commands and your password again after 10 minutes.
3. Watch it
Each run is an ordinary job, so its output is in the device's Activity. It ends as OK, Partial (some files couldn't be read; the rest are saved), Failed with restic's reason, or Missed (the machine never picked it up; it's tried again when it's online). A repository left locked by a run that was cut off: the device's Backups, the plan's ⋯ → Remove stale locks.
Restoring files
From the device's Backups section or a run: Restore…, pick a snapshot, then everything in it or Pick files… to browse it and tick what you want. Then:
- Onto: this machine or another one, such as a laptop's replacement, or somewhere to look without touching the original.
- Where: Into a folder, the default, with the files under it in their own folders, so nothing is overwritten. Or Back where they were (Linux and macOS): files with the same names are replaced, others are left alone.
Proxmox backups
A Proxmox VE node's agent reads its backup jobs, the guests no job includes, every backup on each storage that holds them, and its recent vzdump runs (which guests failed and why, from each run's log). Each node's Backups card, on the Backups page and on its device page, shows them all.
- Backup jobs: New backup job (guests: All, and new ones or These; storage; schedule; mode; how many to keep), and on each one Run now, Edit…, Turn on or off and Delete. A job made in Proxmox for a pool shows as Pool name. These are Proxmox's own jobs (Datacenter → Backup), so Proxmox runs them on time even with CERMM off.
- Not backed up: the guests no job includes, with Back up now.
- A guest's backups: Back up now, Protect (so pruning never removes it), Delete, and Restore…, As a new guest (the next free ID, new MACs) or over the existing one (it's stopped and replaced; asks first).
- Add storage: a Proxmox Backup Server datastore, a CIFS share or an NFS export, added with
pvesm add.
Everything is vzdump, qmrestore, pct restore, pvesm or pvesh as a signed job through the Run drawer, so it needs Run commands and is in the audit log.
Proxmox Backup Server
Install the CERMM agent on the PBS machine like on any Debian machine (Add device). Its device page and the Backups page then show each datastore with its space, the last verify and garbage collection, recent tasks, the version and the certificate's fingerprint. Verify now and Garbage collection now are a click away.
To use it from Proxmox VE: on the node's card, Add storage → Proxmox Backup Server. The server address, datastore and fingerprint are filled in from the PBS machine's agent. Give a PBS user or API token (user@pbs!token) and its secret, and optionally a namespace. Tick Encrypted to have Proxmox make an encryption key on the node (/etc/pve/priv/storage/<name>.enc). Copy that key somewhere safe: without it those backups can't be restored.
Alerts
The Backup rule (Settings → Alerts) is a number of days, 2 to start, and a device can have its own or turn it off (its Alerts section → Alert rules).
- A failed file backup is a warning on any machine.
- No good backup in that many days is a warning on servers only. A laptop that's away isn't news.
- A Proxmox guest whose last backup failed, or which has none that recent, is a warning on its node, one line per guest.
- A PBS datastore 90% full, or a failed verify or garbage collection, is a warning on the PBS machine.
They go out as notifications like any other, and appear in Needs attention as Backups failing and Backups behind.
Secrets
A destination's password or key and the encryption password are kept on the CERMM server and sent only inside a signed job for one machine. They are blanked from the job once the agent has it, from its output, and from the audit log. Machines keep nothing between runs, apart from restic's cache.
Not yet
- Restoring Windows files back where they were. Restore into a folder and move them.
- Backing up a Hyper-V host's VMs.
- PBS sync, prune and verify jobs from CERMM. Set those up in PBS; CERMM shows how they ran.