Skip to content

Checklist: would your backup survive ransomware?

Check what is already true today. At the end you get a score and, for each open item, what to do. It applies to any backup tool that writes to an S3 bucket; the shortcuts point to Arkame where it has the path ready.

Nothing leaves your browser: answers are saved only on this device, and you can clear them anytime.

  1. Why: Without versions, an encrypted file overwrites the good one, and the next backup copies the damage.

  2. Why: Versioning alone doesn't protect against whoever holds the key: it deletes versions. Object Lock without default retention protects nothing either.

  3. Why: In Governance, anyone with the right permission can bypass the lock. In Compliance, nobody deletes before the period ends.

  4. Why: Ransomware often stays quiet before it acts. If retention expires before you notice, the good versions may already be gone.

  5. Why: A public bucket exposes backups to anyone who finds the address.

  6. Why: A whole-account key, leaked from the server, opens every bucket and every setting.

  7. Why: With Object Lock, Arkame deletes no versions at all; the leftover permission only helps whoever steals the key.

  8. Why: The forgotten copy of the secret is the door nobody watches.

  9. Why: A copy within the server's reach gets encrypted along with it; a copy in the same building burns in the same fire.

  10. Why: A manual backup is a backup from whenever someone remembered.

  11. Why: A backup that has never been restored is still a hypothesis, and the day of the attack is the worst day to find out.

  12. Why: Copying the files of a database in use often produces a copy that won't open.

  13. Why: A backup that stopped silently is discovered on the day you need it.

  14. Why: With an admin's password, the attacker turns off the backup or deletes whatever isn't locked.

Result

0 of 14 items done

At risk

At least one essential item is missing. Start there: those decide whether the backup survives the attack.

What's missing

  • Versioning is on for the backup bucket.essential

    What to do: Turn on versioning in the bucket: Backblaze B2 (on by default), Wasabi, AWS. Arkame's agent refuses buckets without versioning.

  • Object Lock is on, with a default retention on the bucket.essential

    What to do: On Wasabi, Object Lock can only be enabled at creation: create a new bucket and point the plan at it. On B2, enable it at creation too, because default retention requires it. Step by step: Backblaze B2, Wasabi, AWS.

  • Default retention is in Compliance mode, not Governance.essential

    What to do: Switch the bucket's default retention mode to Compliance. On Wasabi it defaults to Governance: see how to switch.

  • The bucket is private: no public access.essential

    What to do: Remove public access in the bucket's settings at the provider (what every bucket needs).

  • The backup key is used only for backups and opens only that bucket. It is not the provider's master key or root account.essential

    What to do: Create a key restricted to the bucket (access policy), swap it on the server with arkame-agent set-storage-keys --restart (commands) and revoke the old one at the provider.

  • The backup lives off the protected server and outside the building.essential

    What to do: Send the backup to a bucket at a cloud provider (compare costs). With MinIO in the same building, the bucket exists but isn't off-site.

  • Someone restored a file from the backup in the last month, and it opened.essential

    What to do: Restore a file to a new folder and open it. In Arkame, under Restore, by search, folders or timeline (restore). Put it on the calendar: every month.

  • Retention lasts longer than it would take you to notice an attack (30 days is a good start).

    What to do: Increase the bucket's default retention. Remember it is also how long nobody can delete anything, including you: weigh it against storage cost.

  • With Object Lock, the agent's key can't delete versions (where the provider lets you choose).

    What to do: On AWS and Wasabi, remove s3:DeleteObjectVersion from the policy (why). Careful: on a bucket without Object Lock, Arkame's retention cleanup needs it.

  • The key's secret isn't in a spreadsheet, chat, email or repository.

    What to do: Generate a new key, swap it on the server (commands), revoke the old one and delete the copies. In Arkame, the key exists only on the server: the panel never receives it.

  • The backup runs on its own, on a schedule, without anyone having to remember.

    What to do: In Arkame, give the plan a schedule (daily or every few hours) under Plans (plans).

  • Databases go into the backup as a dump, not as the files of a running database.

    What to do: Create a dump before the backup: in Arkame, with the plan's before-backup command; with the agent in Docker, where those commands don't run, schedule the dump on the server itself (cron) into a folder included in the plan (details).

  • An alert arrives when a backup fails or a server stops responding, and someone reads that email.

    What to do: In Arkame, check under Settings → Organization → Email notifications that both alerts are on. They go to the account's billing email: make sure it reaches someone who acts.

  • The provider's console and the backup panel require two-step verification.

    What to do: Turn on two-step verification in the provider's console and, in Arkame, under Settings → Profile.