Operator notice

Right after the setup token, the setup wizard shows a short notice, Your responsibility as operator. It says what kind of tool Restow is: a tool for backup and archiving that writes your data to storage you operate and helps you get it back. It does not run that storage for you, and it cannot make your infrastructure safe. What happens on the hardware and storage layer is yours to take care of. Restow cannot be set up until you have accepted the notice.

What it says

The notice has eight points. In short:

1. No replacement for a backup strategy. Follow the 3-2-1 rule: three copies, on two kinds of media, one of them off site or offline, and keep one independent copy that Restow can neither reach nor delete. During the beta, Restow must never be your only backup.
2. Hardware and storage. Servers, disks, networks and storage targets, and their redundancy, capacity and health, are your responsibility. If a target fails, fills up or is lost without a separate copy, Restow can neither repair it nor bring the data back.
3. Ransomware and deletion. Data is only immutable if the storage makes it immutable. Without WORM or Object Lock on the target, anyone who can reach it, ransomware or a compromised account included, can change or delete backups and archive alike.
4. Encryption keys. Your data is encrypted with keys derived from the master key of this installation. Keep that key safe and apart from the data. If it is lost, nobody can decrypt the data.
5. Network and access. The security of the server, the network, the accounts and the credentials that reach Restow and its storage is yours: updates, firewall, HTTPS, strong sign-in, and who may access what.
6. Test your restores. Do it regularly and check the results, in addition to the verification Restow runs itself.
7. Archive and GoBD. The archive features are designed for GoBD-compliant use. Whether your whole procedure is compliant is yours to answer: process documentation, retention periods, access rights, organizational measures and the storage behind the archive. Restow gives no legal or tax advice.
8. No warranty. Restow comes under its license terms, without warranty beyond them and beyond what mandatory law requires.

Which license applies to which part of Restow is on License and editions.

On immutability in 0.4.7, specifically: point 3 of the notice is about the storage you run, and it stays true. Restow does not make storage immutable on its own. Since 0.4.0 each repository has a setting for immutable backups, off until an administrator turns it on. On S3 with Object Lock, Restow then writes every backup object with a lock that the storage enforces (compliance or governance mode, 1 to 3650 days) and renews it while the data is in use. On a directory (the Docker volume, an NFS share) it offers only a deletion delay that Restow keeps itself, which protects against misuse of Restow and is not immutability. The installation’s default repository cannot be made immutable. The archive’s item records carry the archive’s own Object Lock retention, and its message content is locked together with the backup data only where immutable backups are turned on. These features were tested against a fake S3 service, not yet against a real one. Ransomware detection marks suspicious restore points and pauses Restow’s retention for them; it does not replace an independent copy. See also Archive and journaling and the roadmap.

You must accept it first

You tick a box that says you have read the notice and understand that, as operator, you are responsible for these points, and continue with the rest of the wizard.

• The server enforces it. The acceptance is sent together with the setup, and without it the server refuses the setup (HTTP status 428, “Operator notice not accepted”). The order of the screens is not the protection: a script that leaves out the acceptance gets the same refusal.
• What is stored. The acceptance is saved in the same transaction as the setup. The version of the text, the time and the client address are stored in the installation settings, the new first administrator is recorded as the person who accepted it, and an entry is written to the audit log (settings.disclaimer_accepted, with the version and where it was accepted). Recording runs in every edition, the viewer for the log is a Business feature, see Audit log.
• Nothing is stored before the end. If you stop the wizard before it finishes, neither the acceptance nor anything else of the setup is left behind.

What you should have in place

The notice is not something to tick and forget. A short checklist for what it asks of you:

• RESTOW_MASTER_KEY is backed up offline, apart from the server, together with your .env. Without it no backup can be read. See Backing up Restow itself.
• The storage has redundancy, you watch its free space and health, and for anything that matters there is a second target (a copy target) or a separate backup of it.
• WORM or Object Lock is set up on the storage where you rely on immutability, the archive above all. For backups, create the S3 bucket with Object Lock, give Restow’s access key no s3:BypassGovernanceRetention, and turn on Change immutability on the repository (see Immutable backups). Restow is only as immutable as the storage under it: a directory gets a deletion delay at best, which is not immutability.
• Someone sees ransomware findings. The events Suspicious backup (signs of ransomware) and Retention still paused after a suspicious backup reach a channel that somebody reads, and an administrator knows how to resolve a retention hold (see Ransomware detection).
• An independent copy exists that Restow cannot reach or delete, and during the beta Restow runs alongside your existing backups.
• You test restores on a schedule, into a place where a mistake costs nothing, and you read the result. See Backup and restore.
• Access is secured: the server is updated (see Updates), only the ports you need are open, the address is served over HTTPS, sign-in uses passkeys where possible, and roles give people no more than they need.
• Restow itself is backed up: its database, .env and chunk store, and you know how to restore without a running server.
• For the archive: your process documentation, retention periods and access rights are written down, and you have had them checked by whoever is responsible for that in your organization, for example your tax advisor.