Ransomware protection: locked backups and a trash

Ransomware doesn't stop at your files. It looks for your backups, and it uses whatever it finds on the computer to get at them: the S3 key in the backup tool's settings, your signed-in browser, your API token. Zaryn's protection is built for that case: **even someone holding your own keys can't destroy what you've protected.** ```diagram type: cards title: Three layers --- 🔒 | Object lock | An object kept until a date can't be deleted or overwritten by anyone, with any key | accent 🗑 | Trash | A delete or an overwrite keeps the old version for N days, and a bucket can be put back as it was at any moment | ⏳ | Delays | Lowering protection waits 3 days and emails you. Until then you can cancel it, and the attacker can't do anything | good ``` ## For your backups: one command ```bash zev backup init zaryn ~/Documents # the bucket's trash is on from the start (14 days) zev backup protect --days 30 # every object locked for 30 days ``` From then on, every object `zev backup` writes is locked for 30 days: packs, indexes, snapshots, keys. The locks are renewed while a snapshot still needs them. Objects nothing needs any more are freed when their lock ends. The backup's short-lived lock files stay unlocked, so they never pile up. ```diagram type: sequence title: The computer is taken over lanes: Ransomware | Zaryn S3 | Your account | You alt: Ransomware with the computer's own S3 key tries to delete and overwrite the backup and is refused because every object is locked; it uses the computer's token to shorten the trash, which only schedules the change three days ahead and emails the owner, who cancels it and restores from a clean computer --- Ransomware -> Zaryn S3 : DELETE every backup object, with the computer's own key Zaryn S3 --> Ransomware : 403 locked until 2026-11-27 note Zaryn S3 : the lock holds against any key | good Ransomware -> Zaryn S3 : overwrite a snapshot Zaryn S3 --> Ransomware : 403 locked Ransomware -> Your account : trash 0 days, with the computer's token Your account --> You : email: lowering protection asked for; it happens in 3 days note Your account : nothing changes until then | warn You -> Your account : Cancel == From a clean computer == You -> Zaryn S3 : zev backup restore latest Zaryn S3 --> You : every piece, checked ``` `forget` respects locks too. A snapshot the keep policy lets go, but which is still locked, stays until the lock ends, and `forget` says so. ## Object lock (S3's API) Any S3 tool that speaks object lock works as it does with Amazon S3: ```bash aws s3api create-bucket --bucket records --object-lock-enabled-for-bucket aws s3api put-object-lock-configuration --bucket records \ --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}' aws s3api put-object --bucket records --key 2026/report.pdf --body report.pdf \ --object-lock-mode COMPLIANCE --object-lock-retain-until-date 2027-01-31T00:00:00Z aws s3api put-object-legal-hold --bucket records --key 2026/report.pdf --legal-hold Status=ON ``` | | | |---|---| | Retention | `GOVERNANCE` or `COMPLIANCE` until a date, per object or as the bucket's default | | Legal hold | `ON` keeps an object with no end date until it's turned off | | What's refused | delete, delete many, overwrite (refused before the upload is read), deleting the bucket | | Read it back | `x-amz-object-lock-*` headers on GET and HEAD, `?retention`, `?legal-hold`, `?object-lock` | **One difference from AWS, on purpose:** an S3 key can only **add** protection: a later date, a stricter mode, a legal hold on. `x-amz-bypass-governance-retention` is not honoured. On Zaryn, lowering protection is done from your account and waits (next section). A stolen key can't do it. - **GOVERNANCE**: you can release it from your account, after the delay. - **COMPLIANCE**: nobody can shorten it, you and Zaryn included. The storage stays on your plan until the date, so choose the days with that in mind. ## The trash In a bucket with a trash, a delete moves the object to the trash, and so does an overwrite (for the old version). It stays there for the bucket's number of days, restorable, and counts on your plan. The trash can also **put the whole bucket back as it was at a moment**. For each object, the version that was there at that moment comes back. That undoes a run of encrypted overwrites in one step. What's there now goes to the trash in its turn, so nothing is lost either way. Open [Storage → S3 → a bucket → Protection](/storage#s3) and choose **Put the bucket back as it was at**, or use the API: ```bash curl -X POST https://api.zaryn.xyz/v1/s3/buckets/photos/trash/restore \ -H "Authorization: Bearer $ZEV_TOKEN" -d '{"since":"2026-10-28T09:00:00Z"}' ``` A bucket can't be deleted while its trash holds anything. ## Lowering protection waits | Raising (at once) | Lowering (waits 3 days, emails you) | |---|---| | a lock or a longer one, a stricter mode | a shorter or no default lock | | a legal hold on | a legal hold off, a governance lock released | | a trash or a longer one | a shorter trash, emptying it | While a change waits, it shows on the bucket's **Protection** panel with a **Cancel** button, and the email links there. If you didn't ask for it, cancel it. Then replace your S3 keys and API tokens: whoever asked has them. Related: [Backup with zev backup](/docs/en/backups), [S3-compatible storage](/docs/en/s3-storage), [Verified storage](/docs/en/verified-storage).