Start
If it fails now: loss and target
The main number for a server is the “Latest copy” in the server list and the “Latest backup” on its page. It answers the question: how much data is lost if the server fails right now.
What the number means
It's the age of the server's freshest copy saved in an accessible storage. “22 min” means: the newest data you can restore is twenty minutes old. Everything that changed on the server after that is lost.
Under the number is when the copy was made and the profile target: “latest copy · today 13:48 · target — within 1 h”.
- “none” and “no backups yet” — there is no saved copy: everything is lost.
- “as of the panel's data” — the agent is offline. The panel will see the backups it made without a connection once it's back, so the actual loss may be smaller.
Where it comes from
- The copy time is the moment the data was collected, not the moment the copy landed in the storage. If parts of the backup were prepared at different times, the earliest one is used.
- Only saved copies count. A backup that didn't reach any storage doesn't lower the number.
- Only accessible storages count. If there is no access to a storage, you can't restore from it right now, and its copies don't count.
- The best storage is used. The copy in “Secondary” is behind and the one in “Primary” is fresh — the number is based on “Primary”.
- The agent is silent — the panel checks the list of snapshots in its repositories once an hour. If it finds a snapshot newer than the known one, it calculates the loss from it.
The number doesn't tell you whether the backup is complete. If the database didn't make it into the latest backup, the number can be small, but the server will be “Critical” with the line “… is not in the backup”. Details — incomplete backup.
Target and profiles
The target is how old the latest copy can be for everything to be fine. It's set by the frequency profile in the protection plan, the “How often” block. There is one profile for the whole server.
| Profile | Backup | Target |
|---|---|---|
| “Critical” | every 30 min | no older than 1 h |
| “Standard” | every 6 h | no older than 12 h |
| “Rarely changes” | daily | no older than 36 h |
The target is longer than the interval: it includes the time to collect and send the backup, plus small delays. The target isn't a promise but a threshold after which the panel starts warning.
The color of the number:
- normal — the copy is no older than the target;
- orange — older than the target, but no older than two targets;
- red — older than two targets.
When a copy is “behind”
This is about each storage separately — the line next to its name on the server:
| In the panel | What it means |
|---|---|
| “22 min ago” | The copy in this storage is within the target |
| “18 h behind” | The latest copy here is older than the target |
| “no access” | The panel can't reach the storage |
| “no backups yet” | No copy has been saved here yet |
On the server page you may also see “36 backups not saved in a row” and the cause: the S3 response code or a restic line. Why exactly it's behind — in the tooltip of the history strip and in the server log.
If the copy in one storage is behind and the one in another is fresh, the server has “Needs attention”: the data is there, but one of the copies isn't being updated.
When there has been no copy for a long time
If no accessible storage has a copy no older than two targets, the server is “Critical”: “No fresh backup in any storage: the latest was 26 h ago”. The copy in each storage is still labeled “… behind”.
What to do: open the server log and look at the latest errors. Common causes — the agent is offline, there is no access to the storage, staging on the server ran out of space. Once it's fixed, you don't have to wait for the schedule — “Back up now”.
Why the loss can be larger than the interval
- The number grows between backups. With a backup every 6 hours, right before the next run the loss is almost 6 hours, and that's normal.
- A backup isn't instant. While it's being collected and sent to the storage, the number keeps growing: before the new copy lands, the loss is the interval plus the backup duration.
- Runs are slightly shifted. Each server has a fixed offset of up to 2 minutes so that servers don't all start at once.
- Upload settings. With the “At night, 01:00–06:00” window, the copy in this storage is behind during the day until night. With a speed limit, the backup takes longer to upload; if it doesn't finish before the next one, the latest ready one is sent.
- Failures. The storage was unavailable, the network dropped, the agent was silent, the server was rebooting — the copy didn't land and waits for the next backup or a retry.
- The backup takes longer than the interval. Then the server has the warning “Backup takes 28 min; scheduled every 30 min”: choose a less frequent profile, or find out what takes the time.
The same article is in the panel, under “Help”.