Bring your own storage

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-29

Restow writes backup data as deduplicated, encrypted chunks (content-defined chunking, SHA-256 hashes, packed into pack files) to storage you choose. The default target needs no extra service at all: local disk on a Docker volume inside the same container, so Restow runs fully self-contained with just itself plus PostgreSQL and no data ever has to leave your server. Point it at S3-compatible object storage, or a mounted NFS share instead, and the storage is exactly as good, cheap, or geographically local as whatever you picked, not a markup on top of it.

Why "bring your own" instead of a Restow cloud

Restow does not operate a hosted storage service, and there is no plan for one. See Your data is your data for the full reasoning. Practically, that means your storage bill is your storage bill: pick a cheap S3-compatible provider, reuse capacity you already pay for, or keep everything on a local disk with nothing metered per gigabyte, per restore, or per API call. More than one storage target per organization is supported: a primary plus a copy is the common pattern for keeping a backup of the backup.

Repositories you can add

Where backups are stored is called a repository: a menu entry Repositories sits under your organisation. The installation owner sets the default repository (a local path or an S3-compatible bucket) under Installation, Default repository, and Restow checks it with a probe before it saves it. Tenants on it stay separated by their own prefix and key. A repository can be:

A local disk.
S3-compatible object storage, with a Hetzner Object Storage preset. It has a location selector (Falkenstein, Nuremberg, Helsinki) that sets the endpoint and the region together, and the Object Lock detection accepts the answers of S3-compatible services such as Hetzner. With Object Lock on the bucket, it can also hold immutable backups, see below.
NFS, added from the web interface under Installation, Network shares, or by an NFS address in the path field of a directory repository (for example 192.168.1.10:/export/backup, nas.local:/volume1/restow or an nfs:// address). The provider owner can test and mount it right there, and Restow fills in the path. When jobs are running, the mount waits until none runs and can be cancelled.

NFS goes through the opt-in mounter container (docker compose --profile mounts up -d mounter, or the installer option --with-mounter). The mounter checks a share before it writes docker-compose.override.yml, restarts the api and worker services and rolls back on failure, and the updater moves it along with every signed update.

Since 0.3.6, when the mounter is not running, the network shares page shows the command to start it, beginning with the installation's directory. If the installation's docker-compose.yml is from before the mounter, the page says so and shows the installer command: running install.sh again replaces the file with the one of the release, keeps the old one as a backup copy and leaves .env as it is.

Since 0.3.6, mounting an NFS export that does not exist on the server says so: "The export path ... does not exist on ...", with how to find the right one. Check what the server exports with showmount -e <server>. On a Synology NAS the path starts with the volume, for example /volume1/restow. With NFSv4 some servers show their exports below a pseudo-root, under different paths, so try NFS version 3. Before, the mount ended with a bare "No such file or directory".

Where backups land, and changing the primary target

Since 0.4.2, Restow names the tenant's effective primary repository where a backup is set up or started: on a guest's page and its "Back up now" dialog, in the Proxmox VE job and connect dialogs, on a machine's and a file share's page and in the job editors, with the installation default on the server's local disk highlighted. The Repositories section and the dialogs that add Proxmox VE nodes, machines and file shares warn "Backups land on the server's own disk" when the primary is a directory on a disk of the Restow server itself, not a network share: if that server or its disk fails, the backups are lost with it.

Since 0.4.5 Restow also says when the directory lies on the server's system disk, the disk under the operating system, Docker and the database: a full system disk stops everything, not only the backups. The api recognises this from inside its container by the device and the block device of the path, the installation default and the mounter's shares included. The Repositories page, the "Backups land in" line of the job editors (with a "System disk" badge) and the dashboard's storage tile warn, and provider admins see on the tile the free space, its trend over the last week and when the disk would be full. Nothing is blocked.

Server and client backups (see server and client backup), file shares (see file shares) and Proxmox VE containers use a restic repository each, on the primary as well, and copy repositories do not cover them. Changing the primary target takes them into account since 0.4.2:

Move existing backups. A background run copies every pack, manifest and key, the manifests of VM and container restore points and the restic repositories of containers, machines and file shares to the new repository, verifies them by size and SHA-256 like packs, waits for running container backups and file share runs, and only then switches the primary. The old location stays attached read-only until you remove it, and it cannot be removed while it alone holds such a repository.
Keep existing backups where they are copies nothing, and is refused while containers or file shares have restic repositories (the dialog shows it disabled), because after such a switch every container and share would find an empty repository on the new primary. Before 0.4.2 every container with an existing repository then failed with "repository does not exist". Promoting a copy is refused for the same reason.
Machines. While a machine of the tenant is active, Restow still refuses every change of the primary, because an active agent keeps writing to the old primary. Revoke or uninstall the machines first, change the primary (a move copies the repositories of the revoked machines too), then enrol the machines again, which creates new repositories on the new primary. With "keep", the repositories of revoked machines stay on the old target, which remains a read-only fallback: browsable and downloadable.

Immutable backups

Since 0.4.0, every repository has an immutability setting of its own. It is off until an administrator turns it on, on the repository's card under Repositories ("Change immutability"), and nothing is locked before that. What it means depends on the kind of repository.

S3 with Object Lock, in compliance or governance mode, for 1 to 3650 days. The storage itself then refuses to delete or overwrite a locked version before its date, whoever asks: Restow, someone holding Restow's access key, a stolen administrator account. Compliance mode cannot be shortened or lifted by anyone, the owner of the bucket included. Governance mode can be lifted by any account that holds the bypass permission (s3:BypassGovernanceRetention); Restow never uses it, and its access key should not have it. Turning the setting on checks the bucket and refuses one without Object Lock. Object Lock can only be enabled when a bucket is created: it cannot be added to an existing bucket.
A directory (the Docker volume, an NFS share) gets only a deletion delay: Restow's own code refuses to delete or overwrite a backup file before the period has passed. That protects against misuse of Restow, such as a stolen administrator account or a retention policy shortened to delete restore points. It does not protect against anyone with access to the server or the share, and the interface says it is not immutability. For real immutability on premises, use an S3 service with Object Lock on a separate machine, as the repository or as a copy.

What is locked, and what is not

Locked are the packs, the committed manifests and the wrapped keys of the chunk store (Microsoft 365, IMAP and Proxmox VE VM disks, and the message content of the archive, which is stored in the same chunk store) and the data, snapshots, keys and config objects of every restic repository (servers and clients, file shares, Proxmox VE containers). Not locked are checkpoints, staging, exports and downloads, and restic's own locks and index files; restic can rebuild the index from the locked packs. The archive's item records keep their own retention, as before.

How the lock follows the data

Every locked object is written with a retain-until date of the period plus 7 days. Because deduplication lets a new restore point rest on packs written months ago, the daily retention job renews the lock of every object still in use once the last complete renewal is 6 days old, so whatever a restore point needs stays locked for at least the period beyond today. When retention or garbage collection meets an object that is still locked, the deletion counts as "not yet": the restore point stays visible and restorable, and the space comes back once the lock has run out, up to the period plus 7 days later.

What you see, and who may change it

The repository card shows the setting in words, the last renewal and the last check, and puts warnings first: objects without a lock, a weaker mode than set, a renewal that is overdue or failed, and deletions waiting for their lock. "Verify now", and the daily retention job, ask the storage for the retention of a sample of recent objects. Restore points show "Immutable until" with a date, in green only when the storage itself reported a compliance retention; governance and a deletion delay are shown neutrally. The dashboard's storage tile and the provider view warn too. Raising the protection is open to whoever may configure the repository. Lowering it (fewer days, a weaker mode, off) is for the provider owner with a sign-in from the last ten minutes, and applies only to data written from then on. Every change and every check is written to the audit log.

What it does not protect against

Someone who controls Restow can stop writing new locks and stop the renewal. What was locked stays locked until its date, but new backups after that are not protected.
A governance lock is lifted by any account with the bypass permission. Give Restow's access key a policy without it, or use compliance mode.
Someone with Restow's key can hide objects behind delete markers or write garbage versions on top. The locked versions stay and can be brought back by removing the newer versions or markers.
The master key is not in the bucket. Keep a copy of it away from the server, or locked data cannot be opened.

The access key of an immutable S3 repository needs s3:GetBucketObjectLockConfiguration, s3:PutObjectRetention, s3:GetObjectRetention, s3:ListBucketVersions and s3:DeleteObjectVersion, and should not have s3:BypassGovernanceRetention, s3:PutBucketObjectLockConfiguration or s3:PutBucketVersioning.

S3 endpoints must use HTTPS

An S3 repository sends its access signatures and every pack to the storage service, so since 0.4.0 a new or changed endpoint over plain http:// is refused, for provider administrators and the installation default too. The one exception is the machine itself (localhost, 127.0.0.1, [::1]). Endpoints saved before keep working, so no backup stops on an update: their repository card, Installation, Default repository and every test say in red that they should move to HTTPS, and changing their location needs https://. Test and development setups can accept plain HTTP with S3_ALLOW_INSECURE=true; never set it in production.

Storage figures and disk space

Since 0.4.1, the Stored figure (the dashboard tile, Repositories, Usage, the statistics and the API) adds the restic repositories of servers and clients, file shares and Proxmox VE containers to the chunk store; before, it counted the chunk store only, so a tenant with 10 GB of container backups saw "Stored 10.9 kB". The usage card shows how much of it is in the chunk store and how much in restic repositories. The deduplication saving, the growth and the chart, now called "Chunk store per day", stay figures of the chunk store, because the restic repositories keep no size history, and "Protected data" still counts the chunk store's sources only.

Since 0.4.0, the dashboard shows storage growth for 1 week, 1 month, 3 months or 1 year, from 3 months on with the estimate as a band between the slowest and the fastest growth, and when the repository runs full at this growth where its free space is known. Every 15 minutes the API also checks the disk under the database and under the local default repository, and warns provider admins below a tenth free, and always below 5 GiB. Since 0.4.5 it watches the server's system disk too, by the same rule.

The storage check: damaged is not the same as unreadable

The storage check reads packs back and compares them with the recorded size and checksum: a sample every week and every pack every month, and "Recovery readiness › Storage integrity" can start a sample, a full check or a re-check by hand. Since 0.4.2 it tells two things apart. A pack is damaged when every repository answered with damage (missing, wrong size, a checksum that differs, not a valid pack, or contents that differ from the index); every object using it is rated "Not restorable" at once. A pack is temporarily unreadable when a repository could not be read for the moment, which proves nothing about the data: a download cut off mid-transfer, a reset connection, a timeout, S3 asking to slow down, or denied access. The check reads such a pack again first, whole, up to three times, and lists what stays unreadable as "temporarily unreadable" with the error, in how many consecutive checks it could not be read and when first and last. Objects using it are rated "Attention". They become "Not restorable" only when a pack is proven damaged, or when it could not be read in 3 consecutive checks over at least 24 hours. Every later check reads the flagged packs first, "Re-check these packs" reads only them again, and when they read intact again the finding ends and the objects' own restore checks rate them again. Reads from S3, restores and restore checks included, also resume a download that breaks off, from the first missing byte.

Stated limits, not hidden ones

The move of restic repositories, the verification by SHA-256 and the resuming of S3 reads were tested against a simulated S3 service and local directories, not against a real S3 provider. A container backup that starts in the API's minute-long storage cache window around the switch can still write to the old primary; the next backup's repository check finds the repository on the new primary.
Mounting an NFS share from the web interface, or from the path field of a repository, was tested against stand-ins, not against a real NFS server. While a mount waits for running jobs, new jobs still start, so on a server that is never idle it keeps waiting.
On local and NFS repositories there is a deletion delay that Restow enforces itself, not immutability: someone with access to the server or the share can still delete the files. Immutable backups need an S3 bucket created with Object Lock. The installation's default repository cannot be made immutable: give the tenant a repository of its own, or an immutable copy.
Immutable backups were tested against a simulated S3 service with Object Lock, not yet against a real S3 service with Object Lock, and not against a real Hetzner bucket. A tenant whose retention schedule was deleted is not renewed, and the space of deleted data comes back only after its lock has run out. How Restow behaves with a bucket-wide default Object Lock retention is untested.
Restow recognises a missing NFS export by Docker's error text, and that text was taken from Docker's documentation, not from a real failed mount.
The Hetzner preset was not tested against a real Hetzner bucket.

How this compares to a SaaS-hosted backup

Most vendor-hosted Microsoft 365 backup products put your data in the vendor's own cloud by definition (that's what "hosted" means), and several are genuinely good at running that infrastructure; see the vendor comparisons for what each one actually documents about where the bytes live. Restow's answer is structural rather than a promise: it is not built to operate that cloud in the first place, so there is nothing to trust beyond your own storage choice and Restow's encryption of what goes into it (see encryption and key handling).

Frequently asked

Where does Restow store backup data?

Wherever you point it: local disk in the same Docker container by default (no extra service needed to start), or S3-compatible object storage, or a mounted NFS share instead. Restow itself does not operate a storage service: there is no "Restow cloud" your data could end up in.

Can I use a Hetzner Object Storage bucket?

Yes, there is a Hetzner Object Storage preset with a location choice: Falkenstein, Nuremberg or Helsinki, which sets the endpoint and the region together. Buckets with a dot in their name are reached by path. The preset was not tested against a real Hetzner bucket.

Can I use an NFS share?

Yes, in two ways. You can add a network share in the web interface (Installation, Network shares), which goes through the opt-in mounter container, or you can type an NFS address such as 192.168.1.10:/export/backup, nas.local:/volume1/restow or an nfs:// address into the path field of a directory repository. In both cases Restow checks the share before it mounts it. Mounting was tested against stand-ins, not against a real NFS server. If the export path does not exist on the server, the message says so and how to find the right one (since 0.3.6).

Can backups be made immutable?

Yes, per repository, since 0.4.0. On an S3 bucket with Object Lock, Restow can lock backup data in compliance or governance mode for 1 to 3650 days, and the storage itself then refuses to delete or overwrite it before the date. The bucket has to be created with Object Lock; it cannot be added later. A directory (local disk or NFS) only gets a deletion delay that Restow keeps itself, which the interface labels as not immutable. It is off until an administrator turns it on.

What does immutability not protect against?

Someone who controls Restow can stop new locks and the renewal: what is locked stays locked until its date, but new backups after that are not protected. A governance lock is lifted by any account with the bypass permission, so give Restow's key a policy without it or use compliance mode. Delete markers can hide locked data, though the locked versions stay and can be brought back. The master key is not in the bucket: keep a copy away from the server. And it was tested against a simulated S3, not yet against a real S3 service with Object Lock.

Can an S3 endpoint use plain http?

Not any more for new ones. Since 0.4.0 a new or changed S3 endpoint over plain http:// is refused, except to the machine itself (localhost, 127.0.0.1, [::1]). Endpoints saved before keep working, and say in red that they should move to HTTPS. S3_ALLOW_INSECURE=true accepts plain HTTP for test and development setups only.

Can I change the primary repository later?

Yes, with "move": since 0.4.2 a background run copies the packs, manifests and keys and also the restic repositories of containers, machines and file shares, verifies them by size and SHA-256, and only then switches the primary. "Keep existing backups where they are" is refused while containers or file shares have restic repositories, because they would find an empty repository on the new primary. While a machine of the tenant is active, no change of the primary is allowed.

What does "Backups land on the server's own disk" mean?

Since 0.4.2 Restow names the repository that backups land in, on the guest's, machine's and file share's pages and in the job editors, and warns when it is a directory on a disk of the Restow server itself (not a network share). If that server or its disk fails, the backups are lost with it. Choose a network share or S3-compatible object storage instead.

What if the storage check cannot read a pack?

Since 0.4.2 that is not called damage. A pack the check could not read for the moment (a download cut off, a reset connection, a timeout, S3 asking to slow down, denied access) is read again, up to three times, and if it stays unreadable it is listed as temporarily unreadable, with the error. Objects using it are rated Attention; they become Not restorable only when a pack is proven damaged or could not be read in three checks in a row over at least 24 hours.

Can I use more than one storage target?

Yes. More than one target per organization is supported, typically a primary plus a copy, so a single storage failure isn't also a backup failure.

Is the data deduplicated?

Yes. Restow uses content-defined chunking, so identical content across items and over time is stored once, hashed with SHA-256, and packed into pack files rather than kept as full duplicate copies.

Why bring-your-own-storage matters, in more depth →