Is a snapshot a backup?

No, and Atlas keeps the two apart. A snapshot is a fast way back on the same storage; a backup lives elsewhere and survives the disk. The picture shows them separately.

Does Atlas use vzdump?

Yes. Underneath, backups are ordinary Proxmox backups; Atlas adds the coverage picture, the checks and the flows on top. Nothing about the dumps is proprietary.

Does it snapshot before updates automatically?

Yes. The safe update flow takes a snapshot before packages are applied, so a bad update has a way back by default.

What does restore look like?

A guided flow: pick the guest and the point in time, see what will be overwritten and what will be lost, confirm, and watch it run. No guessing at flags.

Does it check that backups actually ran?

Yes. The built-in Watch sentinel raises a finding when a guest misses its schedule or a target fills up, before the missing backup becomes an incident.

Do my backups leave my infrastructure?

No. Backups go wherever they are pointed inside the same infrastructure. Atlas draws the picture locally; nothing is uploaded anywhere.

Backups and the way back, told as one story

A backup is only half of safety; the other half is the way back. Atlas puts Proxmox backups, snapshots and restore into one picture: what is protected and how recently, what would be lost, and how a bad change gets rolled back.

Why backup routines rot

On a stock host, backup truth is scattered: vzdump jobs in one screen, snapshots per guest in another, storage capacity in a third. Whether every guest that matters is actually covered is a question nobody can answer from one place.

Snapshots and backups get confused, and the confusion costs data. A snapshot on the same disk is not a backup; a nightly dump with no restore test is a hope, not a plan.

And the way back is rarely rehearsed. When a change goes wrong at two in the morning, the question is not whether a backup exists somewhere; it is how fast the known good state comes back and what gets lost in between.

Keeping guests safe by hand

The routine experienced admins run manually:

List every guest and decide which ones would hurt to lose; protection follows that list, not the other way around.

Schedule vzdump jobs, then check they actually ran and fit inside the window.

Snapshot before every risky change, and remember to delete old snapshots before they eat the pool.

Watch backup storage capacity, because a full target fails silently at the worst time.

Test a restore now and then, on a guest that does not matter, to know the chain works.

After a bad change, find the right snapshot or dump, restore it, and reconstruct what happened since.

How Atlas holds the whole story

Coverage, snapshots and the way back live on one screen instead of five.

Coverage at a glance

Which guests are backed up, how recently and to where is one view. The guest that quietly fell out of the schedule stands out instead of hiding.

Snapshots where they belong

Snapshots are created, listed and cleaned per guest, with age visible, so forgotten snapshots stop eating pools.

A snapshot before every risky step

Critical flows take a snapshot before touching the system, so the way back exists before the risk is taken.

Restore as a guided flow

Bringing a guest back runs as a checked flow: what will be restored, what will be overwritten and what gets lost in between is stated before anything runs.

Rollback with visible impact

Rolling back is not a blind jump: the affected guest, the disks and the window of changes that will disappear are shown first.

The storage behind the backups

Backup targets and their capacity are part of the same picture, so a filling target is caught before jobs start failing.

Frequently asked

Is a snapshot a backup?: No, and Atlas keeps the two apart. A snapshot is a fast way back on the same storage; a backup lives elsewhere and survives the disk. The picture shows them separately.
Does Atlas use vzdump?: Yes. Underneath, backups are ordinary Proxmox backups; Atlas adds the coverage picture, the checks and the flows on top. Nothing about the dumps is proprietary.
Does it snapshot before updates automatically?: Yes. The safe update flow takes a snapshot before packages are applied, so a bad update has a way back by default.
What does restore look like?: A guided flow: pick the guest and the point in time, see what will be overwritten and what will be lost, confirm, and watch it run. No guessing at flags.
Does it check that backups actually ran?: Yes. The built-in Watch sentinel raises a finding when a guest misses its schedule or a target fills up, before the missing backup becomes an incident.
Do my backups leave my infrastructure?: No. Backups go wherever they are pointed inside the same infrastructure. Atlas draws the picture locally; nothing is uploaded anywhere.

Related entries

How many backups to keep: the real question is not the count, it is how far back you can go Seven daily backups protect perfectly against the mistake you notice today and not at all against the damage you notice in a month. Retention is not a number, it is a decision about reach.
Testing a restore: a green job is not proof Everyone knows the sentence "an untested backup is not a backup" and nobody acts on it. This entry is about what testing actually means, because a job that looks successful is not a test.
A snapshot is not a backup: where the difference lies and why it matters A snapshot lives on the same disk. If the disk goes, the snapshot goes with it. A backup sits somewhere else, and that is the only real difference.
If a machine's configuration file breaks: where the old copy lives Every machine has a small text file. If it breaks, only that machine is affected, and the old copy sits in two places most people never look.