Restore and restore checks

You restore a file share from a restore point on the share’s page: Servers & clients → File shares, choose the share, tab Restore points. Who may: tenant administrators for their own shares, and provider administrators working in a tenant. Tenant users and restore operators have no self-service restore of shares in 0.4.7; the file restore of the restore role covers machines and Proxmox VE, not file shares.

Browse, search and versions

The Restore points tab lists every restore point with its number of files, what it added and the number of permission entries it holds. Open one to browse its folders and files as they were at that time.

Find a file. Search the names of all files in all restore points of the share. A search needs at least three characters of the name. Results can be Deleted (no longer in the newest restore point), and Versions shows every version of a file with its modification time and the restore points it is in.
The search uses a file catalog that Restow keeps up to date after every backup. It is not available while the catalog is being built, when a provider administrator switched it off (File catalog in the runner settings), or for a share with more than 20 million files. Browsing a restore point works without it.
A version that is only in restore points that retention has since removed is marked “only in restore points that were removed”.

Restore

Select files or folders (or Everything in the restore point) and choose Restore. The dialog asks Where to:

Choice	What happens
Download as ZIP	The server reads the files from the repository and prepares one ZIP. It does not hold the permissions, and it needs no mounter and no Allow restore to this share.
The original location	The files go back into the share they came from, to the same place. You choose If a file exists, see below. Needs Allow restore to this share on this share.
A new folder in the same file share	The files go into `Restow-Restore-<date>-<time>` in the root of the share (for example `Restow-Restore-20261016-103000`). Needs Allow restore to this share.
Another file share	The files go into a Folder of another share that has Allow restore to this share on. Empty: a new folder named after the date and time. The folder is created when it does not exist. Under this choice, Repeat on a schedule as a copy job opens the copy job editor with source, target and folder filled in.

If a file exists (only for the original location):

Overwrite. The restored file replaces the one there when it differs.
Keep both. A file that is missing is restored. A file that is the same (same size and modification time) is left alone. A file that differs stays, and the restored copy is placed next to it as <name> (restored 2026-10-16 1030)<ext>. Nothing is overwritten.
Skip. A file that exists is left alone; the restored one is left out.

The two other options of the dialog:

Restore the permissions. Puts owner and permissions back as they were backed up. It is on for the original location and for a new folder, and off for another share: the other file server may not know the same accounts, and an unknown account in a permission can lock people out of the restored files. Switch it on there only when both servers know the same accounts.
Verify written files. Reads every file back after it was written. Slower. On by default for NFS targets (with soft mounts a write that timed out could otherwise be lost silently), off for SMB.

Then Please check shows what goes where, and Restore confirms. The restore appears in Runs as a run of the kind Restore with live progress, and ends as Completed or With warnings (for files that could not be written: a name the target cannot hold, missing rights, no space). Restores and copies hold the target share like a backup: one run per share at a time, so a restore into a share waits while a backup of it runs.

A restore never deletes anything and never writes outside its folder. The only run that deletes is a mirror copy job, inside its own target folder.

Allow restore to this share is off by default, on every new share. While it is off, no restore and no copy job can write into the share. The switch is in the add dialog and under Settings of the share, and changing it is recorded in the audit log. The reason is simple: a restore to the original location can overwrite files that people work on. Switch it on only for shares you want to restore into, for example a second site’s share that receives copies. A share that does not allow restores says so in the dialog (“This file share does not allow restores into it.”) and links to its settings. The cause of a refused restore is share.restore_not_allowed.

Permissions

On SMB, a restore writes the permissions back file by file, as far as the account of the target share may. It tries the owner with the access control list and the auditing entries first, then the access control list with the owner, then the list alone, and counts the level reached per file.

To set owners, the account needs SeRestorePrivilege on the server. To set auditing entries, it needs SeSecurityPrivilege. Without them, the restore still writes the content and ends With warnings with share.acl_partial (“Permissions were not saved or restored for every file”). The files that kept the permissions they inherited from the target are listed as Permissions not restored.
DOS attributes (read-only, hidden, system, archive) and the creation time are set last, on a best-effort basis. The attributes that mark an offline file are never restored.
SMB data into an NFS share, or the reverse: the content is restored, the permissions are not, with one warning.
NFS: NFSv4 and POSIX ACLs are restored on a best-effort basis. With root_squash the owner cannot be changed: Owner not restored.
The permissions of a single file are restored only together with the file.

What a restore point does not hold, and cannot give back: alternate data streams, access times, and any consistency across files. See Troubleshooting and limits.

Restore checks

A backup nobody has read back is unproven. Every restore point of a share is therefore checked, automatically:

At the end of every backup run, the runner picks up to 20 random files whose modification time is older than the start of the run by an hour, and that did not change while they were hashed. It posts their SHA-256 with the restore point.
The server reads exactly these files back from the share’s repository with restic and compares them with the SHA-256. This is the restore check. It runs right after the backup, for every new restore point, and also on request: Run a restore check now on the share’s Overview.
Once a week the server runs restic check on 5 % of the data of the share’s repository. The part rotates, so the whole repository is read over about five months, and damage found there rates the share red until a later check finds it whole.

How a restore point is rated. Recovery readiness rates a share by its newest restore point, one row per share (see Restore readiness):

Rating	Meaning
Ready (green)	The restore check read back every sampled file and each matched.
Yellow	The restore check passed, but the backup ended With warnings (some files could not be read), or the restore point had no samples (below). The share list shows this state as Check overdue, whatever the cause; the restore point’s own line says whether it is warnings or missing samples.
Not restorable (red)	The restore check failed (a file did not match or could not be read), or a newer repository check found damage. The event is Restore check failed.
Unverified	The restore point exists but has not been checked yet.
No backup yet	Nothing to check until the first backup has finished.

A rating that is older than eight days is marked Overdue in Recovery readiness, whatever its colour. A share that is in a backup job and has no backup 24 hours after it was put into the job is marked the same way (“No backup within 24 hours after the share was put into a backup job”).

No samples. When every file of a share changed within the hour before the backup (a busy share, or a first backup right after a migration), there is nothing stable to read back. The restore check then rates the restore point yellow with the note “No samples to check yet: every file changed within the hour before the backup”, and the restore point shows No samples yet. The next backup takes samples from files that stay unchanged. A copy job does not copy such a restore point.

A restore check proves that sampled files can be read back and are unchanged. It does not prove that every file can be, and the weekly restic check reads only a part of the repository each time. For the full explanation of what a check proves see How Restow checks that a backup can be restored.

Restore without Restow

A file share’s repository is a plain restic repository, file-shares/<share id>/ in the tenant’s primary repository (restic’s config, data/, index/, keys/ and snapshots/). Each restore point holds the files under /share and the permissions under /.restow (acls.jsonl.gz and manifest.json). With the repository password (Show password under Settings, audited) and access to the storage, restic can open it and restore the files, without Restow. The permissions file is a gzip of JSON lines with the security descriptors, and restic does not apply it: a restore without Restow brings back the content, not the permissions. In 0.4.7, restow-restore does not open the repository of a file share for you. Keep the repository password somewhere outside Restow.