The connectors and the rights they ask for
A connector reads the catalogue your backup tool already keeps and restores a sample into the scratch space; no connector writes to a source, and a write is refused before it leaves. Each connector has a note — what it reads, in which mode and with which rights — which you acknowledge in the app before the source is first read; the same note is below, with the tool versions it was tested on. In version 1.0.0 the connectors read on Linux and on macOS; on Windows they follow in a later version.
Files on a local disk
Reads a folder on a local disk: it lists the tree — up to 64 levels and 200,000 entries — and opens only the sampled files, never following symbolic links. It needs no credentials: it reads with the rights of the account the app runs under, and only the folder you named.
The least rights: a read-only account, access list or mount. A read may move a file’s last-access time where the system does not prevent it; the app writes nothing.
Files on a mounted network share
A network share is read through the same connector as a local disk, once the system has mounted it: the app does not connect to the server itself, and the mount stays the system’s. Name the mounted folder as the source; a UNC path (\\server\share) is refused, because it would lead to a host you have not declared.
The least rights: mount the share read-only (-o ro) or with an account that only reads. The system may move a file’s last-access time on a read, where the mount allows it.
Files on a host over SSH (SFTP)
Reads a folder on a host over SFTP: listing and reading files, nothing else — no write, rename or delete is ever sent. The credentials — a key with its passphrase, or a password — reach the connectors’ process alone. The host’s key is accepted at the first connection, by its fingerprint, and a changed key stops the connection.
The least rights: on the host, OpenSSH’s read-only SFTP subsystem (ForceCommand internal-sftp -R in a Match block, with ChrootDirectory and no port forwarding) or an account with read-only rights. Tested against OpenSSH 9.9’s SFTP server; other servers were not verified.
restic
Runs restic from your computer with --no-lock and --no-cache only and reads its JSON answers: it lists the snapshots and their files, reads the repository’s configuration and restores the sample into the scratch space; it never writes to the repository and leaves nothing in a cache. The repository’s password is given to restic on its standard input, for the read alone. In version 1.0.0 the local repository is accepted; repositories over SFTP, REST and S3 follow.
restic has no read-only key: any password opens the whole repository. The least rights are therefore on the storage under the repository — a read-only mount or permissions on a local repository, a read-only SFTP account, an S3 key with the list and read rights alone — which make a write fail even with the password. Tested with restic 0.18 and 0.19; a version from 0.20 on is refused until a version of the app has been tested on it.
BorgBackup
Runs BorgBackup 1.x from your computer with --bypass-lock: it lists the archives and their files and extracts the sample into the scratch space; it never runs check or info, which would write to the repository or the cache. The passphrase is given to borg through a file descriptor, for the read alone, and Borg’s working folders live in the scratch space. In version 1.0.0 the local repository is accepted; repositories over SSH follow.
A Borg repository’s passphrase decrypts every archive and has no read-only form, and Borg may write to the repository after an interrupted operation, even with --bypass-lock. The least rights are therefore on the storage under the repository: a read-only mount or permissions, which make any write fail; a local repository is read only when no interrupted operation is behind it. Tested with BorgBackup 1.2 and 1.4; Borg 2 is refused.
Kopia
Connects Kopia to the repository read-only (--readonly) and checks the read-only state before any read: it lists every user’s and host’s snapshots, reads a folder’s entries and restores the sample. The configuration, the logs and the cache live in the scratch space; the password is not kept in the system’s keyring and is given to kopia for the read alone.
The repository’s password opens the whole repository and has no read-only form. The least rights: the repository’s folder without write permission for the reading account — a read-only mount, access list or permissions — and a repository that carries the .shards file, made with Kopia 0.9 or later; an older repository, in which Kopia would write that file, is refused. Tested with Kopia 0.22 and 0.23; a version from 0.24 on is refused until a version of the app has been tested on it.
S3-compatible stores
Reads an S3-compatible bucket through GET and HEAD requests only: the list of objects and their versions, the write-protection state (Object Lock) and the sample, by ranged requests. A listing is a snapshot of the prefix: if the prefix changes between the listing and a read, the read is refused and the listing is made again.
The least rights: a read-only key whose policy grants s3:ListBucket, s3:ListBucketVersions and s3:GetBucketObjectLockConfiguration on the bucket and s3:GetObject, s3:GetObjectVersion, s3:GetObjectRetention and s3:GetObjectLegalHold on its objects — and nothing else; kms:Decrypt only for objects encrypted under a KMS key. The connection is over HTTPS alone.
Cloudflare R2
Cloudflare R2 is not part of version 1.0.0. The connector reads an R2 bucket through its S3-compatible API, with GET and HEAD requests only: the list of objects and the sample. The bucket’s lock rules are not read, so the copies’ write protection stays unstated.
The least rights: an R2 token with “Object Read only”, scoped to the bucket. No Cloudflare API token is asked for.
PostgreSQL database dumps
Reads PostgreSQL database dumps — pg_dump in the custom, directory, tar or plain format, and gzipped — and base backups (pg_basebackup, with a backup_manifest), from a folder on disk: their header and table of contents only, as bytes, executing nothing from the file. A database test loads the dump into a scratch PostgreSQL engine bundled with the app and runs the queries you named.
It needs no credentials: the rights are those of the folder read — a read-only account, access list or mount. Formats: pg_dump’s archive versions from PostgreSQL 10 to 19, and manifests in versions 1 and 2.
MySQL and MariaDB database dumps
Reads MySQL or MariaDB database dumps (mysqldump, mariadb-dump) and Percona XtraBackup or MariaDB Backup copies in a folder: their header comments and control files only, executing nothing from the file. A dump written with --compact or --skip-comments has no header: only the file’s own facts remain. A database test loads the dump into a container started through Docker or Podman on your computer, after your consent to the image; without a container engine, the test is not available.
It needs no credentials: the rights are those of the folder read. Formats: the mysqldump and mariadb-dump headers, the control files of XtraBackup 8.4 and of MariaDB Backup 10.11 to 12.3.
Backup files in SQL Server’s own format
Reads, from a folder, backup files in SQL Server’s own format, by their size and the format’s signature alone; nothing else is interpreted. The database test for SQL Server is not available in version 1.0.0.
It needs no credentials: the rights are those of the folder read.
Windows Server Backup
Windows Server Backup is not part of version 1.0.0. The connector reads the backup sets through Get-WBBackupSet, locally on the server or over WinRM on HTTPS, with fixed PowerShell templates; it never runs a recovery to the original locations.
The least rights: Windows Server Backup documents no read-only role, and an account in the Backup Operators group can also make and restore backups; the connector’s note says so before the first connection.