Points and copies

A point is one backup

A backup, also called a restore point, is one run: the server's data at a moment in time. Inside is everything in the plan, plus a description: what's included and how to bring it up. The backup time in the panel is the moment the data was collected.

A copy is a backup in one storage

The agent sends the same backup to each storage in the plan separately. A backup in one storage is a copy. Two copies in two storages are two independent ways to restore the same data.

All backups of a server are on its page, on the “Backups” tab. A row is a backup, a column is a storage, and the cell shows the state of the copy:

Why copies in storages differ

Each storage has its own upload queue. This way a slow or unavailable storage doesn't hold up the others or the next backup. As a result:

• a storage gets one upload at a time, and no more than one backup waits for it. When a newer one is ready, it replaces the waiting one, and the older one's copy is “skipped”. There is no queue of skipped backups: only the latest ready one catches up;
• the upload failed — the same backup is retried after 1, 2, 4… up to 30 minutes, until a newer one is ready;
• the “At night, 01:00–06:00” window — during the day the copy here is behind; at night the latest ready backup is sent;
• a speed limit — the backup takes longer to upload; if it doesn't finish before the next one, the latest ready one is sent;
• “sending off” — new backups don't go here; saved ones stay;
• the storage was added to the plan later — it has no older copies;
• each storage has its own cleanup rules — a backup is already deleted in one and still kept in another.

Upload settings — on the storage page, the “Servers” tab → “Edit”.

Directories and volumes — as of the upload

Database dumps, adapter snapshots and host settings are prepared once and are the same in all storages. restic reads directories and volumes straight from disk when it sends a copy to each storage. If “Secondary” got its copy 20 minutes later than “Primary”, the files in it are 20 minutes newer, but the dumps are the same.

Complete and incomplete backup

Databases and application data are required in the plan. If at least one required component didn't make it into the backup — for example, pg_dump failed — the backup is incomplete. Everything else in it is saved, and its copies land in the storages as usual. But:

• the server is “Critical” with the line “PostgreSQL 16 is not in the backup: …”; in the server list — “Not in the backup: …” or “Backup incomplete: 2 components missing”;
• on the server overview, in “Not in the backup” — “no dump”;
• in the server log — “Not backed up: …” with the reason as is.

The “Latest copy” counts an incomplete backup too, so check the server status as well. Host settings aren't required: without them the backup counts as complete.

If the log shows “Not on the server: …”, a path from the plan is gone from the disk and there is nothing to copy — remove it from the plan, see Gone from the server.

Checked by a restore

The “Restore” column shows whether this backup was restored with arcula restore and what was confirmed: “created”, “structure checked”, “checked by reading”, “component restored”, “project restored”. The tooltip says what exactly was checked, where, and how long it took. The “restored only” filter leaves only such backups.

The integrity of the data in the storage itself is checked separately, every night — data check.

Pinned points

The star in a backup row makes it a pinned point: cleanup won't delete it. The “pinned only” filter leaves only such backups. Details — pinned points.