---
title: "Outpost Backup"
description: "How Outpost Backup protects endpoint files and whole systems, where the data goes, who holds the keys, and how coverage is measured."
url: "https://support.outpostplatform.com/backup/"
product: "depot"
type: "concept"
status: "draft"
ai_summary: "Outpost Backup, built into the agent on every plan: file backups of users' standard folders plus policy paths, optional system images (Windows disk, Linux whole system, macOS data volume in Preview), primary and secondary copies, encryption on the endpoint, escrowed or zero-knowledge keys, recovery kits for kopia, coverage statuses, and third-party monitoring."
availability:
  plans: ["home-lab", "essentials", "enterprise", "msp"]
  platforms: ["windows", "linux", "macos"]
  permission: "backup:read"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/backup/index.md"
license: "CC BY 4.0"
---

# Outpost Backup

Outpost Backup backs up endpoint files and whole systems with the same agent
that monitors and patches them, to storage you choose. It also collects the
status of other backup products you already run, so one **Backup** page in the
console answers whether every endpoint's data is protected. Backup is part of
every plan. This page explains what is protected, where it goes, who holds the
keys, and how coverage is measured.

## What is protected

Backup is off until a [profile](/automation/profiles/) turns on
`backup.enabled` for an endpoint. Backup settings apply to endpoints, so you
assign them to the whole client, a site, a device group, or one endpoint, not
to a person. Once backup is on, the endpoint backs up on its own schedule and
uploads whenever it can reach its destination.

There are two kinds of backup.

### File backups

A file backup copies each local user's standard folders: Desktop, Documents,
Pictures, Videos (Movies on macOS), and Music, plus Favorites on Windows. The Downloads folder is
added when `backup.include_downloads` is on. A folder that Windows or the Linux
desktop has redirected to another place is followed there. On Windows, Outlook
`.pst` files anywhere in a user's profile are included.

You add more paths with `backup.include_paths` and leave paths out with
`backup.exclude_paths`. Temporary files, browser caches, the recycle bin or
trash, Outlook `.ost` files, and cloud placeholder files are always left out.

The agent reads files from a point-in-time snapshot where the system offers
one, so files that are open and changing are copied consistently: Volume
Shadow Copy on Windows, an LVM or btrfs snapshot on Linux where the volume
uses one of them, and a local APFS snapshot on macOS. Other Linux volumes are
read live.

### System images

When `backup.system_image` is on, the endpoint also backs up the whole system
on a separate schedule, weekly by default. What an image holds depends on the
operating system:

| Operating system | What a system image holds |
| --- | --- |
| Windows | A block image of each disk, read from a Volume Shadow Copy. Used space is copied and free space is skipped. The partition layout is recorded with it. |
| Linux | Every local filesystem, plus the disk layout: partitions, LVM, filesystem labels, the bootloader, and `/etc/fstab`. |
| macOS (Preview) | The APFS data volume, captured from a local snapshot. |

System images go to the primary destination only. See
[Configure backups with policy](/backup/configure-backup/) for the schedules.

## Where backups go

Each endpoint has a primary copy and, if you set one, a secondary copy. The
secondary is an independent copy at another destination, with its own key,
schedule, and retention, for a 3-2-1 arrangement.

A copy goes to a [storage destination](/depot/storage/):

- Outpost Cloud Storage
- Your own S3-compatible bucket
- A local or network path on the Outpost server
- A Windows network share, for Windows endpoints only

An endpoint writes to an S3-compatible bucket directly, with short-lived
signed requests that Outpost issues for each operation, so the bucket's
credentials never reach the endpoint. If the endpoint cannot reach the bucket,
it uploads through Outpost instead. A destination on the Outpost server is
always reached through Outpost.

Unless a profile names a destination, backups go to the client's default
destination, then the MSP's default, then the Outpost server's own disk.
Outpost Cloud Storage is the MSP's default unless you set another, except on
Home Lab.

:::note
Home Lab uses your own S3-compatible storage only. Essentials, Enterprise, and
MSP include an Outpost Cloud Storage allowance, and backups on Outpost Cloud
Storage count toward it. See [Plans and limits](/account/plans-and-limits/).
:::

## Encryption and keys

Every backup is compressed, deduplicated, and encrypted on the endpoint before
anything leaves it, with AES-256-GCM. Each copy of each endpoint is a separate
repository with its own random key, which the endpoint generates. The endpoint
keeps its key protected on the machine: with DPAPI on Windows, and in a file
only root can read on Linux and macOS.

Who else holds the key is a choice you make for each client:

- **Escrow, the default.** Outpost keeps a sealed copy of each key. That is
  what lets a technician browse backups in the console, download files, and
  restore one endpoint's files onto another.
- **Zero-knowledge.** Outpost keeps no key at all. Only the endpoint can open
  its own backups, and anything else needs the recovery kit.

A recovery kit holds a repository's location and key, so you can restore it
with the open-source kopia tool, without Outpost. See
[Backup encryption keys and recovery kits](/backup/encryption-keys/).

Backups are also protected against deletion. Outpost refuses to delete any
backup object younger than `backup.delete_floor_days`, 7 days by default, and
applies S3 Object Lock to each object when the bucket supports it, so
ransomware on an endpoint cannot erase that endpoint's recent backups. This
covers every destination Outpost signs or relays requests for. A Windows
network share is written by the endpoint directly, so the delete floor does
not apply there.

## Verification

Every 7 days by default, each endpoint checks that its backups can be
restored: it verifies a sample of the repository and restores a few files to a
temporary folder. A failed check raises an alert. Outpost also raises a tamper
alert when a snapshot that retention still keeps is missing from the
repository.

## Coverage

The **Backup** page counts each endpoint in one of four statuses, across
Outpost Backup and every third-party product that reports on it:

| Status | Meaning |
| --- | --- |
| **Protected** | A recent backup succeeded. |
| **Stale** | No success within twice the backup interval, or 48 hours for another product. |
| **Failed** | The latest attempt failed. |
| **Unprotected** | No backup has ever succeeded. |

See [Monitor backup coverage](/backup/coverage/).

## Third-party backups

The agent detects other backup products on the endpoint and reports their last
result, whether or not Outpost Backup is on. Connectors read the same from a
vendor's API: N-able Cove Data Protection, Datto BCDR, Acronis Cyber Protect
Cloud, Veeam Service Provider Console, and Axcient x360Recover. See
[Monitor third-party backup products](/backup/third-party-backups/).

## Restores

A technician restores files to their original location, another folder,
another endpoint, or a zip download, and exports a Windows system image as a
VHD. When `backup.self_service_restore` is on, which is the default, people
restore their own files from the [tray app](/tray/). See
[Restore files and systems](/backup/restore/).

## By operating system

| Capability | Windows | Linux | macOS (Preview) |
| --- | --- | --- | --- |
| File backup | Yes | Yes | Yes |
| Snapshot for open files | Volume Shadow Copy | LVM or btrfs, where the volume uses one | Local APFS snapshot |
| System image | Block image of each disk | Every local filesystem and the disk layout | APFS data volume |
| Export an image as a VHD | Yes | No | No |
| Windows network share destination | Yes | No. The next destination is used. | No. The next destination is used. |
| Self-service restore from the tray | Yes | Yes | Yes |
| Third-party product detection | Yes | Yes | Yes |

## Permissions

| Permission | Allows | Built-in roles that hold it |
| --- | --- | --- |
| `backup:read` | Coverage, status, runs, snapshots, and the connectors list | Owner, Support Manager, Field Technician, Support Rep, Accounting |
| `backup:browse` | The names of files inside snapshots, and file versions | Owner, Support Manager, Field Technician |
| `backup:restore` | Restores, zip downloads, and starting a backup | Owner, Support Manager, Field Technician |
| `backup:manage` | Connectors, and linking reported devices to endpoints | Owner |
| `backup:keys` | Zero-knowledge mode and recovery kits | Owner |

On the MSP plan, practice-level roles get these from permissions they already
hold: `endpoint:read` gives `backup:read`, `endpoint:write` gives
`backup:browse` and `backup:restore`, and `storage:manage` gives
`backup:manage` and `backup:keys`. See
[Roles and permissions](/depot/roles-and-permissions/).

## Related

- [Configure backups with policy](/backup/configure-backup/)
- [Backup encryption keys and recovery kits](/backup/encryption-keys/)
- [Restore files and systems](/backup/restore/)
- [Monitor backup coverage](/backup/coverage/)
- [Backup policy settings](/backup/policy-settings/)
- [Storage destinations](/depot/storage/)