How to use Akamai (Linode) Object Storage for server backups

What it costs

Billing starts, prorated, when you create your first bucket or access key, even with nothing stored. As of October 2026:

• $5 a month for the account, with 250 GB of storage included.
• $0.02 per GB stored above 250 GB ($0.024 in Jakarta, $0.028 in São Paulo).
• No request fees. Akamai is evaluating them for E3 endpoints, but not before October 1, 2027.
• Uploads are free. Downloads count against your transfer pool, even to a Linode in the same data center. Object Storage adds 1 TB to the global pool (not to the separate Jakarta and São Paulo pools); past the pool, transfer costs $0.005 per GB.

Restoring all 600 GB to a server draws 600 GB from the transfer pool. If the pool is already used up, that restore adds $3.00.

Pick a region and its endpoint

Each region has S3 endpoints of type E0 to E3. E2 and E3 are the current platform, with higher limits and every new feature; E0 and E1 are legacy. Use E3 where offered. Access keys and the Linode API use the region ID (us-ord); S3 tools use the endpoint hostname (us-ord-10.linodeobjects.com).

Akamai's endpoint types page lists every region. This Linode CLI command lists the endpoints your account can use:

linode-cli object-storage endpoints

Each endpoint sits in one data center, so pick a region where your servers are not. Akamai's 11 nines of durability on E2 and E3 excludes fire, flood, human error and a compromised account. Between October 6 and November 16, 2026, Akamai turns on default AES256 encryption at rest for E2 and E3; earlier uploads stay unencrypted.

Create an admin key and the bucket

1. In Cloud Manager, open Object Storage, then the Access Keys tab, and click Create Access Key. Confirm Enable Object Storage if asked.
2. Label it, for example admin-workstation, select the region, and leave Limited Access off.
3. Copy the access key and secret key. The secret is shown once.

This unlimited key reaches every bucket in that region. Keep it on your workstation, never on a server. Set up an AWS CLI profile for it:

[profile akamai-admin]
region = us-east-1
endpoint_url = https://us-ord-10.linodeobjects.com
request_checksum_calculation = WHEN_REQUIRED
response_checksum_validation = WHEN_REQUIRED

[akamai-admin]
aws_access_key_id = <access-key>
aws_secret_access_key = <secret-key>

• endpoint_url sends every command in this profile to the Chicago endpoint.
• region only signs requests; the endpoint decides where they go. Akamai's own example creates an Atlanta bucket with --region=us-east-1.
• The checksum lines are Akamai's workaround for AWS CLI 2.23.0 and later, whose uploads can fail with SignatureDoesNotMatch, MissingContentLength or NotImplemented. Akamai says it may not always work and recommends AWS CLI 2.22.35.

Decide on Object Lock now: it can only be turned on when the bucket is created, and only through the S3 API. To create a locked bucket:

aws s3api create-bucket --bucket acme-server-backups --object-lock-enabled-for-bucket --profile akamai-admin

Versioning turns on with it. Without Object Lock, use Create Bucket in Cloud Manager instead, then turn versioning on yourself; none of Akamai's own tools manage it:

aws s3api put-bucket-versioning --bucket acme-server-backups --versioning-configuration Status=Enabled --profile akamai-admin

Names are 3 to 63 lowercase letters, numbers, periods and dashes, unique in the region across all accounts, and can't contain admin on E2 or E3.

Give each server a limited key

Create one key per server. In Cloud Manager, choose Create Access Key, select the region, turn on Limited Access, set the backup bucket to Read/Write and every other bucket to None. Or, with the Linode CLI:

linode-cli object-storage keys-create --label web-01-backups --bucket_access '[{"region": "us-ord", "bucket_name": "acme-server-backups", "permissions": "read_write"}]'

• region takes the region ID; permissions is read_write or read_only.
• Permissions can't be changed later: create a new key, move the server to it, and revoke the old one.
• By default, a limited key covers up to 25 buckets and an account holds up to 100 keys.

Akamai enforces limited keys by writing a bucket policy for you. If you ever apply your own bucket policy, merge it with the existing one, or the limited keys start getting 403 errors.

Configure s3cmd on the server

s3cmd is what Akamai's lifecycle guides use, and it avoids the AWS CLI checksum problem. Install it with sudo apt install s3cmd (2.4.0 on Ubuntu 24.04) and write its config by hand, because the access test in s3cmd --configure fails on Akamai even when every setting is right:

[default]
access_key = <access-key>
secret_key = <secret-key>
host_base = us-ord-10.linodeobjects.com
host_bucket = %(bucket)s.us-ord-10.linodeobjects.com
bucket_location = US
use_https = True

• host_base is the endpoint hostname; host_bucket is the template for addressing a bucket by name.
• bucket_location = US: Akamai says to keep US whatever region the bucket is in.

Run chmod 600 /root/.s3cfg, since the secret sits there in plain text. Then list the bucket; empty output means an empty bucket and a working key:

s3cmd ls s3://acme-server-backups

Upload backups on a schedule

Give each backup a dated name, so nothing overwrites it, and store a checksum beside it. This script archives two directories with tar and uploads both files:

#!/bin/sh
set -eu
NAME="web-01-$(date +%F).tar.gz"
cd /var/backups
tar -czf "$NAME" /etc /var/www
sha256sum "$NAME" > "$NAME.sha256"
s3cmd put --no-progress --multipart-chunk-size-mb=100 "$NAME" "$NAME.sha256" s3://acme-server-backups/web-01/
rm "$NAME" "$NAME.sha256"

• set -eu stops at the first failure, so a failed upload never reaches rm.
• --multipart-chunk-size-mb=100: s3cmd uploads larger files in parts, 15 MiB by default. With Akamai's 10,000-part limit, that caps an archive at about 146 GiB; 100 MiB parts raise it to about 976 GiB. --no-progress keeps cron mail short.

Make it executable with chmod 700 and schedule it (more on cron):

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
30 3 * * * root /usr/local/bin/akamai-backup.sh

Expire old backups with a lifecycle policy

<LifecycleConfiguration>
  <Rule>
    <ID>expire-backups</ID>
    <Filter><Prefix>web-01/</Prefix></Filter>
    <Status>Enabled</Status>
    <Expiration><Days>30</Days></Expiration>
    <NoncurrentVersionExpiration><NoncurrentDays>7</NoncurrentDays></NoncurrentVersionExpiration>
  </Rule>
  <Rule>
    <ID>abort-stale-uploads</ID>
    <Filter><Prefix></Prefix></Filter>
    <Status>Enabled</Status>
    <AbortIncompleteMultipartUpload><DaysAfterInitiation>3</DaysAfterInitiation></AbortIncompleteMultipartUpload>
  </Rule>
</LifecycleConfiguration>

• Expiration 30 days: in a versioned bucket, the backup becomes a noncurrent version 30 days after upload.
• NoncurrentVersionExpiration 7 days: the old version is deleted for good a week later, so a backup lives about 37 days and an accidental delete can be undone for a week. Akamai doesn't support NewerNoncurrentVersions.
• AbortIncompleteMultipartUpload clears unfinished uploads, which are billed, after 3 days.

Apply it from your workstation with an s3cmd config for the admin key, saved as ~/.s3cfg-admin, then read it back:

s3cmd -c ~/.s3cfg-admin setlifecycle lifecycle.xml s3://acme-server-backups

s3cmd -c ~/.s3cfg-admin getlifecycle s3://acme-server-backups

The first prints Lifecycle Policy updated. A new policy replaces the old one whole. Rules run from midnight in the endpoint's local time, so a 1-day rule deletes an object the midnight after it turns 24 hours old.

What Object Lock adds

Versioning alone doesn't stop a stolen server key. Without Object Lock, a Read/Write key can permanently delete any version by its ID, suspend versioning and rewrite the lifecycle policy. With Object Lock, set a default retention so every new version is held:

aws s3api put-object-lock-configuration --bucket acme-server-backups --object-lock-configuration '{"ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "GOVERNANCE", "Days": 14}}}' --profile akamai-admin

• Any key that can write can still add a delete marker, which hides an object; its versions stay held. A new default retention applies only to versions written afterwards.
• In compliance mode, no one, Akamai included, can delete or shorten a hold until it ends or the account is deleted.
• Keep retention shorter than the lifecycle window: 14 days of lock inside 37 days of life.
• Check the setting with aws s3api get-object-lock-configuration --bucket acme-server-backups --profile akamai-admin.

Verify and restore a backup

s3cmd du s3://acme-server-backups/web-01/

That prints the size and object count. It proves uploads landed, not that they restore, so download one backup with its checksum:

mkdir -p /tmp/restore-test && cd /tmp/restore-test && s3cmd get s3://acme-server-backups/web-01/web-01-2026-10-04.tar.gz s3://acme-server-backups/web-01/web-01-2026-10-04.tar.gz.sha256

sha256sum -c web-01-2026-10-04.tar.gz.sha256 && tar -tzf web-01-2026-10-04.tar.gz > /dev/null && echo OK

sha256sum -c checks the download against the hash taken before upload, and tar -tzf reads the whole archive; then extract it somewhere scratch and check the files (testing a restore). To recover an overwritten or deleted backup, list its versions and fetch one by ID with the admin profile:

aws s3api list-object-versions --bucket acme-server-backups --prefix web-01/ --profile akamai-admin

aws s3api get-object --bucket acme-server-backups --key web-01/web-01-2026-10-04.tar.gz --version-id <version-id> web-01-2026-10-04.tar.gz --profile akamai-admin

Linodes and their backups in one account

If your servers are Linodes, a bucket in the same account shares their login, billing and cancel button, and so does the Linode Backups service. A bucket in another region survives a data center loss, not a compromised or cancelled account; Akamai's own durability page suggests a second region or a second provider. Keep one more copy with another company, per the 3-2-1 rule, and encrypt backups before upload.

Limits and common errors

• A single upload tops out at 5 GB; multipart parts are 5 MiB to 5 GiB, up to 10,000 parts and 5 TiB per object.
• Per account and endpoint, by default: 1,000 buckets; 500 TB and 500 million objects on E3, 100 TB and 100 million on E2.
• Requests over a bucket's per-second limit get a 503; on E2 and E3 the default is 500 uploads a second. Multipart downloads aren't supported; use byte-range requests.

• SignatureDoesNotMatch, MissingContentLength or NotImplemented uploading with the AWS CLI: use s3cmd, the checksum settings above, or AWS CLI 2.22.35.
• 403 with a limited key: the key wasn't given that bucket, or a custom bucket policy replaced Akamai's.
• 409 BucketAlreadyExists: the name is taken in that region, or a bucket you deleted less than an hour ago hasn't released it.

Frequently asked questions

What is the S3 endpoint for Linode Object Storage?

Each region has its own hostname, such as us-ord-10.linodeobjects.com for Chicago. Cloud Manager shows it under each bucket's name, and linode-cli object-storage endpoints lists yours.

How much does Akamai Object Storage cost?

As of October 2026, $5 a month with 250 GB of storage and 1 TB of transfer added to your pool, then $0.02 per GB stored. There are no request fees.

Does Linode Object Storage support Object Lock?

Yes, on every endpoint type, in governance and compliance modes. It has to be turned on when the bucket is created, through the S3 API; Cloud Manager can't manage it.

Can I limit a Linode Object Storage key to one bucket?

Yes. Create a limited access key and give it Read/Write or Read on that bucket and None on the rest. Permissions are fixed at creation.