Restore

There are three ways to get files back from an endpoint backup. None of them overwrites anything on the machine.

Way	Use it when
Restore onto the machine	The machine is running and its agent is connected. The files land in a new folder.
Browse and download as ZIP	You want the files on your own computer, or the machine is gone.
Restore without Restow	Restow itself is not available.

All three start from the Snapshots tab of the endpoint (“Restore points”): open the endpoint, pick a snapshot, and click through its folders. Select files or folders in the list. A selected folder includes everything inside it. Every successful backup creates a snapshot.

Restore onto the machine

1. Select the files and folders, then choose Restore to the machine.
2. Optionally enter a target folder: an absolute path on the machine.
3. Confirm with Request restore.

The machine starts the restore with its next contact, usually within a few minutes. If it is off or offline, the request waits until it is back. You can follow the run under Runs on the overview of the endpoint, which shows the folder it restored into.

• Default target. Without a target folder, the agent creates a new folder named Restow-Restore-<yyyyMMdd-HHmmss> inside the first folder that is backed up.
• The target must not exist or must be an empty folder. Otherwise the run fails with the code target_not_empty, and nothing is touched. The agent also tells restic --overwrite never and --verify. The files that are on the machine now stay as they are.
• File names with *, ? or [ are matched exactly.
• You can select up to 200 items per restore.
• The agent leaves folders named Restow-Restore-* out of later backups, so restored files are not backed up a second time.
• A revoked endpoint takes no restore, because it takes no tasks. Download the files as a ZIP instead.

The request and the end of the restore are recorded in the audit log (endpoint.restore.requested, endpoint.restore.finished). If a restore fails, see Troubleshooting.

Browse and download as ZIP

Browsing and downloading work on the server. The machine does not have to be online, and a revoked endpoint can still be browsed and downloaded.

1. Select the files and folders, then choose Download as ZIP.
2. Your browser downloads the ZIP.

How it behaves:

• Up to 50 paths per ZIP. If you need more, select a parent folder.
• Browsing lists one folder at a time, up to 5000 entries per folder. If a folder has more, the interface says the list is cut. Select the folder itself to include everything inside it.
• The ZIP shows the folder you selected (docs/a.txt, not home/anna/docs/a.txt).
• Symbolic links and special files carry no content and are not in the ZIP. The interface marks them.
• Restow checks first that every selected path exists in the snapshot. If one does not, the request fails instead of breaking off in the middle of a download.
• The ZIP is built while it is sent and nothing is cached on disk. If reading fails along the way, the connection is broken off, so you never get a ZIP that looks complete and is not.
• Large folders over very slow connections: the server keeps the connection open as long as restic delivers. A proxy with a short idle timeout in front of Restow can cut it.
• The server runs a limited number of restic processes at the same time (6 in total, 3 per tenant). If the limit is reached, the interface asks you to try again in a moment.

Browsing and downloading are recorded in the audit log (endpoint.snapshot.browsed, endpoint.snapshot.downloaded).

Restore without Restow

The backup of an endpoint is a plain restic repository. With the repository password and access to the storage target, you can restore it with restic alone, even if your Restow server is gone.

1. Open the endpoint, the Settings tab, and the card Restore without Restow.
2. Choose Show repository password and confirm. Restow shows the password. It is not stored in the browser and is hidden again when you close the window.
3. Keep the password in a password manager.

Showing the password is recorded in the audit log (endpoint.repository.password.revealed).

On a local storage target, the repository is the folder endpoints/<endpoint id> inside the storage path. The command then reads:

restic -r /path/to/storage/endpoints/<endpoint id> restore latest --target /restore

Replace /path/to/storage with the folder of your storage target. restic asks for the repository password. The command restores the newest snapshot into /restore. For an S3 storage target, open the bucket with restic directly (-r s3:..., with endpoints/<endpoint id> as the prefix), as long as the repository lies at that path.

The password decrypts the whole backup

Anyone who has the repository password and can read the storage target can read every backed-up file of that endpoint. Keep the password safe.

If you want to be able to restore after you have lost the Restow installation, keep the password yourself before you need it. Without the database and the master key, the password cannot be reconstructed. It exists only on the server (encrypted) and on the endpoint itself.

Restore tests

A backup that nobody has read back is unproven. After every new good backup, Restow proves that files can be read back.

How it works

1. After each successful backup, the agent picks up to 20 random files from the snapshot and reports their path, SHA-256 and size. The files are regular, non-empty, at most 256 MiB each and at most 1 GiB in total. The hash is taken from the file on disk, but only for files that are provably unchanged since the snapshot (same size and modification time before and after hashing). A later mismatch therefore points at the backup, not at an edit made afterwards.
2. The server reads these files out of the repository with restic dump, computes their SHA-256 and compares it with the reported value. The result is green only if all hashes match and at least one file was tested. A file that differs, is missing or cannot be read makes the snapshot red. If the repository was only busy, nothing is rated and the job is repeated.
3. Additionally, the server gives the agent a verify_sample task with the same files. The agent restores them into a temporary folder below its data directory, compares the SHA-256, deletes the copy and reports per file (hash_mismatch, missing, not_regular, read_error). This becomes a second report for the same snapshot.
4. If either of the two fails, the endpoint is red.

You can start a test yourself with Run restore test on the endpoint. It needs a successful backup first. The results are listed under Reports, with the differences if there are any. The reports say whether a result was “Read back by the server” or “Restored on the machine”. The server keeps the samples for 90 days.

Readiness states. The rating belongs to the backup that was checked. A green test of an older backup does not count for a newer one.

State	Meaning
No backup yet (no_backup)	There is no good backup yet.
Not verified (unverified)	A backup exists, but no restore test has checked exactly this backup.
Ready (green)	The restore test of the newest backup passed.
Attention (yellow)	The test passed, but the backup was partial: some files could not be read.
Not restorable (red)	A restore test of the newest backup failed, or a newer repository check found damage.

A rating that is older than 8 days is shown as Overdue. Endpoints appear in the Recovery readiness overview next to mailboxes and OneDrives. See How Restow checks that a backup can be restored for the same idea applied to mailboxes.

A restore test proves that the sampled files come back intact. It does not prove every file, and it does not test a full restore of the whole machine.

Repository check and retention

Two more jobs run on the server, without the machine.

• Repository check: once a week, restic check reads one twentieth of the stored data, in a fixed order, so the whole repository is read over roughly five months. It results in green or red. Damage raises the alert “Storage damage found” and turns the endpoint Not restorable.
• Retention: once a day, the server removes snapshots beyond the kept numbers (30 daily, 12 weekly and 12 monthly by default). See Profiles, schedule and hooks.

Both results are listed under Reports of the endpoint.