{"id":74875,"date":"2026-08-17T01:52:50","date_gmt":"2026-08-17T07:52:50","guid":{"rendered":"https:\/\/www.scalahosting.com\/blog\/?p=74875"},"modified":"2026-08-17T01:52:51","modified_gmt":"2026-08-17T07:52:51","slug":"spanel-immutable-backups-s3-object-lock","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/blog\/spanel-immutable-backups-s3-object-lock\/","title":{"rendered":"How to Enable Ransomware-Proof Backups in SPanel with Amazon S3 Object Lock"},"content":{"rendered":"\n

Amazon S3 Object Lock stores backups on a write-once-read-many (WORM) basis: once SPanel uploads a backup into a locked bucket, nothing can change or delete it until the retention period expires, not even your AWS account\u2019s root user in compliance mode. You enable Object Lock and a default retention period on the bucket in AWS, then ScalaHosting’s team adds that bucket as an S3 backup destination in SPanel. The lock lives on the storage side, not in the panel.<\/p>\n\n\n\n

Why ransomware goes for your backups first<\/strong><\/h2>\n\n\n\n
\"How<\/figure>\n\n\n\n

Modern ransomware crews rarely start by encrypting your files. They start by hunting your backups. In a 2024 Sophos study<\/a> of 2,974 organizations hit by ransomware, 94% reported that attackers tried to compromise their backups, and 57% of those attempts succeeded. The cost gap is brutal: median recovery ran $3 million when backups were compromised, eight times the $375,000 when they survived.<\/p>\n\n\n\n

The logic is simple. A business that can restore doesn\u2019t pay. A business that can\u2019t restore negotiates.<\/p>\n\n\n\n

For a small company with its store, bookings, and email on one server, this changes what \u201chaving backups\u201d means. A copy on the same server dies with the server. A copy in ordinary cloud storage survives only until someone with stolen credentials deletes it. Real protection is a copy nobody can delete for a fixed window, including you. That is what Amazon S3 Object Lock provides, and SPanel works with it today.<\/p>\n\n\n\n

Two SPanel facts before the walkthrough. Every ScalaHosting managed VPS includes SPanel\u2019s complete backup system at no extra cost: four destinations can run simultaneously (local disk, a remote server, Amazon S3 or any S3-compatible provider, and Backblaze B2), each on its own retention schedule. And SShield, SPanel\u2019s security layer, blocks 99.998% of attacks in real time. Locked backups exist for whatever slips through.<\/p>\n\n\n\n

What Object Lock actually does<\/strong><\/strong><\/h2>\n\n\n\n
\"How<\/figure>\n\n\n\n

Object Lock is an Amazon S3 bucket feature that enforces WORM storage: write once, read many. Three terms carry the whole concept.<\/p>\n\n\n\n

Retention period.<\/strong> A fixed length of time during which an object version cannot be overwritten or deleted. Set a default retention period on the bucket, and every new object placed in it is protected for that duration from the moment of upload.<\/p>\n\n\n\n

Compliance mode.<\/strong> The strict variant. According to AWS documentation<\/a>, a version locked in compliance mode can\u2019t be overwritten or deleted by any user, including the AWS account root user, and its retention period can\u2019t be shortened. The only way to remove the data early is to close the entire AWS account.<\/p>\n\n\n\n

Governance mode.<\/strong> The flexible variant. Protected against normal deletion, but users holding the special s3:BypassGovernanceRetention permission can still remove locks or delete objects. AWS positions it as a way to test retention settings before committing to compliance mode.<\/p>\n\n\n\n

<\/th>Governance mode<\/th>Compliance mode<\/th><\/tr><\/thead>
Delete before retention expires?<\/td>Only with a special bypass permission<\/td>No one, including account root<\/td><\/tr>
Shorten the retention period?<\/td>Yes, with the bypass permission <\/td>Never<\/td><\/tr>
Best for<\/td>Testing your configuration<\/td>Production ransomware protection<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

One mechanic worth knowing: permanent deletion of a locked version is refused with Access Denied, while a simple delete only hides the object behind a removable delete marker. An attacker can make your backup list look messy. They cannot make the data go away.<\/p>\n\n\n\n

For help choosing between the modes, see our guide on Object Lock compliance vs governance mode.<\/p>\n\n\n\n

Where the lock is configured (and why it isn\u2019t in SPanel)<\/strong><\/h2>\n\n\n\n

You won\u2019t find an \u201cenable immutability\u201d switch inside SPanel. The lock is a property of the bucket, enforced by Amazon on Amazon\u2019s infrastructure. SPanel\u2019s job is to deliver backups into that bucket according to a schedule; the default retention then protects every object the moment it lands.<\/p>\n\n\n\n

That separation is the security model. The credentials on your server can only write backups; the lock configuration answers solely to your AWS identity, ideally behind multi-factor authentication. An attacker who fully owns the server still can\u2019t reach the immutability rules. SPanel writes; you read.<\/p>\n\n\n\n

Part 1: Prepare the locked bucket in AWS<\/strong><\/h2>\n\n\n\n

These steps happen in the Amazon S3 console. The flow looks like this.<\/p>\n\n\n\n

Step 1 – Create a bucket with Object Lock enabled.<\/strong> In the S3 console, choose Create bucket<\/strong>, name it, and pick a region. Under Bucket Versioning<\/strong>, choose Enabled<\/strong> (Object Lock works only on versioned buckets). Under Advanced settings<\/strong>, find Object Lock<\/strong>, choose Enable<\/strong>, acknowledge the warning, and create the bucket. An existing bucket can be locked from its Properties<\/strong> tab instead.<\/p>\n\n\n\n

One thing to bear in mind: enabling Object Lock is permanent. You can\u2019t disable it later or suspend versioning on that bucket.<\/p>\n\n\n\n

Step 2 – Set the default retention period.<\/strong> Open the bucket\u2019s Properties<\/strong> tab, scroll to Object Lock<\/strong>, and choose Edit<\/strong>. Enable Default retention<\/strong>, pick a retention mode, and set the period in days. From then on, every backup SPanel uploads gets a \u201cretain until\u201d date automatically.<\/p>\n\n\n\n

Thirty days is a sensible starting point for most small businesses: it covers the usual gap between intrusion and discovery without locking a year of storage into your bill.<\/p>\n\n\n\n

Step 3 – Create dedicated credentials for SPanel.<\/strong> Create an access key for backups that can list the bucket and read and write its objects, nothing more. Do not grant it s3:BypassGovernanceRetention, rights to change the Object Lock configuration, or account-level administration. These keys will live on your server, so scope them as if an attacker will eventually read them. With compliance mode, even that worst-case scenario leaves your backups untouchable.<\/p>\n\n\n\n

Part 2: Add the bucket as a backup destination in SPanel<\/strong><\/h2>\n\n\n\n

With the locked bucket and its scoped credentials ready in AWS, the SPanel side is what delivers backups into it on schedule. For your convenience, this step is handled by ScalaHosting’s technical team.<\/p>\n\n\n\n

Send them the bucket name, its region, and the dedicated access key and secret from Part 1. They configure the destination on your server, verify the credentials, and set the retention schedule you want.<\/p>\n\n\n\n

That schedule is worth thinking through before you reach out. Each SPanel destination carries its own retention plan across four tiers, each with its own “how many to keep” count. The table below is a good example of what a backup policy can look like for a business:<\/p>\n\n\n\n

Tier<\/th>When it runs<\/th>Keep<\/th><\/tr><\/thead>
Hourly<\/td>Business hours<\/td>Most recent day<\/td><\/tr>
Daily<\/td>Every day<\/td>One week<\/td><\/tr>
Weekly<\/td>Every Sunday<\/td>One month<\/td><\/tr>
Monthly<\/td>The 1st of each month<\/td>Six months<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Keep your other destinations running alongside: local backups restore fastest for everyday mistakes, while the locked S3 copy is your disaster asset. SPanel runs each destination independently, throttles backup CPU so live sites stay responsive, and can sync database point-in-time recovery archives (snapshots as often as every five minutes) to the same S3 destination.<\/p>\n\n\n\n

What an attack looks like with the lock in place<\/strong><\/h2>\n\n\n\n

An attacker gets in with stolen admin credentials, encrypts the sites, wipes the local backups, then finds the S3 keys and goes after the offsite copies. Every permanent delete comes back Access Denied; simple deletes merely stack delete markers on top of locked versions. The retention clock, set weeks ago in an account the attacker can\u2019t reach, keeps ticking.<\/p>\n\n\n\n

Shortly after, you learn about the breach and you kick the attacker out. It’s time to recover the data. In SPanel you browse the S3 restore points, pick one from before the intrusion, and restore a full account or individual files. A database can be restored under a different name first, letting you inspect last Tuesday\u2019s data beside the current state.<\/p>\n\n\n\n

SPanel\u2019s full-server rebuild reads from local or remote backups, not directly from S3. If the entire server is lost and the bucket holds your only copy, seed a remote backup server from the bucket first, then run the full restore against it. The data survives either way; the path differs.<\/p>\n\n\n\n

Limitations and costs to plan for<\/strong><\/h2>\n\n\n\n

Locked storage is billed storage.<\/strong> Every backup occupies the bucket for its full retention window, no matter what. Size the lock window and the SPanel schedule together, and add an S3 lifecycle rule that permanently expires old noncurrent versions once their locks lapse.<\/p>\n\n\n\n

Compliance mode is absolute.<\/strong> Nobody can shorten it, and Object Lock can\u2019t be switched off once enabled. Test with governance mode first, then commit.<\/p>\n\n\n\n

Immutable is not the same as clean.<\/strong> Backups taken while malware sat undetected on your site preserve the malware faithfully. The defense is retention depth: keep enough history to reach back before the compromise.<\/p>\n\n\n\n

The lock protects the copies, not the live site.<\/strong> Object Lock shortens recovery; SShield, sane passwords, and updates still do the preventing.<\/p>\n\n\n\n

The schedule is server-wide.<\/strong> SPanel\u2019s backup schedule covers all accounts on the server (individual accounts and databases can be excluded), so plan retention at the server level.<\/p>\n\n\n\n

Before you rely on it<\/strong><\/h2>\n\n\n\n
    \n
  1. Run a trial with governance mode or a 1-day compliance window.<\/li>\n\n\n\n
  2. After the first backup, try to permanently delete a test object version in the AWS console. Access Denied is the answer you want.<\/li>\n\n\n\n
  3. Do a test restore of one file and one database through SPanel.<\/li>\n\n\n\n
  4. Switch the bucket default to compliance mode with your production window.<\/li>\n\n\n\n
  5. Add the lifecycle rule for expired versions, and review window length against storage cost quarterly.<\/li>\n<\/ol>\n\n\n\n

    FAQ<\/strong><\/h2>\n\n\n\n

    Q:<\/strong> Does SPanel support Amazon S3 Object Lock?<\/strong><\/p>\n\n\n\n

    A:<\/strong> SPanel backs up to any Amazon S3 bucket, locked buckets included. The lock is a bucket property AWS applies to everything SPanel uploads, so no SPanel-side setting is needed: configure the lock in AWS, have ScalaHosting’s team point SPanel at the bucket, and every backup is immutable on arrival.<\/p>\n\n\n\n

    Q:<\/strong> Can ransomware delete my S3 backups if it steals the keys from my server?<\/strong><\/p>\n\n\n\n

    A:<\/strong> Not while the retention period is active. S3 refuses permanent deletion of a locked version regardless of which credentials ask, and in compliance mode that includes the AWS account root user. Stolen keys can at most add delete markers, which are reversible.<\/p>\n\n\n\n

    Q:<\/strong> Should I use governance mode or compliance mode for backups?<\/strong><\/p>\n\n\n\n

    A:<\/strong> Validate with governance mode, then run compliance mode in production, since it removes the bypass path an attacker with elevated AWS permissions could use. The trade-off is rigidity: compliance-locked data is immovable until it expires.<\/p>\n\n\n\n

    Q:<\/strong> What retention period should I set?<\/strong><\/p>\n\n\n\n

    A:<\/strong> Long enough to cover the gap between compromise and discovery, short enough that the storage bill stays rational. Thirty days suits most small businesses; regulated industries often need far longer. The period can be extended later but never shortened.<\/p>\n\n\n\n

    Q:<\/strong> Can I get the same protection without AWS?<\/strong><\/p>\n\n\n\n

    A:<\/strong> Yes. SPanel supports S3-compatible providers, several of which offer their own object lock. Backblaze B2 is the budget favorite; see our guide to immutable website backups with Backblaze B2 and SPanel.<\/p>\n\n\n\n

    Q:<\/strong> How is this different from locking a backup inside SPanel?<\/strong><\/p>\n\n\n\n

    A:<\/strong> SPanel\u2019s own lock protects a restore point from rotation cleanup, handy for milestone snapshots. S3 Object Lock is enforced at the storage layer and stops deletion by anyone. Different problems, complementary protections.<\/p>\n\n\n\n

    Q:<\/strong> Do immutable backups make my business HIPAA or SEC 17a-4 compliant?<\/strong><\/p>\n\n\n\n

    A:<\/strong> They support those requirements rather than satisfy them outright; regulators assess your whole process. See our deep dive on how WORM backups support HIPAA and SEC 17a-4, and confirm specifics with your compliance advisor.<\/p>\n\n\n\n

    Backups that stay yours<\/strong><\/h2>\n\n\n\n

    Every ScalaHosting managed VPS ships with SPanel and its full backup, restore, and disaster-recovery system included, with no add-on fees. Pair that with one locked S3 bucket, and the next ransomware crew that comes hunting for your backups finds a vault it cannot open.<\/p>\n\n\n\n