Connect JetBackup 5 to AWS S3 & Wasabi with Object Lock

Backing up your customers’ data is a core responsibility for any hosting provider. Even with regular backups, ransomware can encrypt the most recent copies and force you to restore from an older snapshot. JetBackup 5’s Object Lock feature tells compatible object‑storage services—such as Amazon S3 or Wasabi—to make a stored object immutable for a defined retention period. Once locked, the data cannot be overwritten or deleted, providing a ransomware‑proof layer for your backups.

What is Object Lock and Why It Matters

Object Lock is a storage‑level protection mechanism that enforces a Write‑Once‑Read‑Many (WORM) policy. After a file is written, it can be read any number of times but cannot be altered or removed until the retention period expires. This means that even if an attacker gains root access to your cPanel server, they cannot delete or modify the backup files already stored in Amazon S3 or Wasabi.

Prerequisites

• A running JetBackup 5 installation on a cPanel/WHM server.
• An AWS S3 bucket or Wasabi bucket with Object Lock enabled at creation.
• Access keys (Access Key ID and Secret Access Key) that have PutObject, GetObject and DeleteObject permissions for the bucket.
• Root access to the server’s command line to install the awscli tools.

Step 1 – Prepare the S3/Wasabi Bucket with Object Lock

Object Lock must be enabled when the bucket is created; it cannot be added later. Follow the provider’s console instructions.

Amazon S3

1. Open the S3 console and click Create bucket.
2. Enter a unique bucket name (e.g., my-backups-2024) and select a region.
3. In the Object Lock section, check Enable Object Lock. Choose a default retention mode (Governance or Compliance) and a default period (e.g., 30 days).
4. Complete the wizard and note the bucket name.

Wasabi

1. Log in to the Wasabi console and go to Buckets → Create Bucket.
2. Enter a bucket name and select a region.
3. Enable Object Lock and set the default retention mode and period.
4. Create the bucket and record its name.

Both services will now reject any DELETE or PUT request that tries to overwrite an object before its retention time ends.

Step 2 – Install the AWS CLI (or Wasabi‑compatible CLI)

The AWS CLI works with Wasabi because Wasabi uses the same S3 API. Install it using the commands that match your server’s operating system.

AlmaLinux / Rocky Linux / RHEL 9 (dnf)

# Install prerequisites
dnf install -y unzip curl

# Download the AWS CLI v2 bundle
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# Unzip and run the installer
unzip awscliv2.zip
./aws/install

# Verify the installation
aws --version

Debian / Ubuntu (apt)

# Update package index
apt update

# Install prerequisites
apt install -y unzip curl

# Download and install AWS CLI v2
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
./aws/install

# Verify the installation
aws --version

For Windows Server, the AWS CLI can be installed via the MSI package from the same URL; the commands above are for Linux only.

Step 3 – Configure the CLI with Your Access Keys

Run aws configure and provide the credentials you created for the bucket. Set the default region to match the bucket’s region.

# Example configuration
aws configure
AWS Access Key ID [None]: YOUR_ACCESS_KEY_ID
AWS Secret Access Key [None]: YOUR_SECRET_ACCESS_KEY
Default region name [None]: us-east-1   # or the Wasabi region, e.g., us-east-1
Default output format [None]: json

The CLI stores the credentials in ~/.aws/credentials and the region in ~/.aws/config. Secure the file with restrictive permissions (600).

Step 4 – Create a JetBackup Destination for S3/Wasabi

In WHM, go to JetBackup 5 » Destinations and click Add Destination. Choose “S3 / Wasabi” as the type and fill in the fields:

• Name: Descriptive name (e.g., “AWS‑S3‑ObjectLock”).
• Bucket: The bucket name you created.
• Region: The bucket’s region (e.g., us-east-1 for AWS or the Wasabi endpoint region).
• Access Key ID / Secret Access Key: The same keys you configured for the CLI.
• Endpoint URL (optional): Leave blank for AWS; for Wasabi use https://s3.wasabisys.com or the regional endpoint.
• Object Lock Mode: Select Governance or Compliance based on the desired strictness.
• Retention Period: Number of days the objects should remain immutable (e.g., 30).

Click Save. JetBackup will now upload backups to the bucket and automatically add the Object Lock headers.

Step 5 – Verify Object Lock Is Applied

After the first backup finishes, confirm that the objects have the correct lock settings.

Using the AWS CLI

# List objects (simple view)
aws s3api list-objects --bucket my-backups-2024 \
    --query "Contents[].{Key:Key,Size:Size}" --output table

# Get lock information for a specific object (replace with your object key)
aws s3api get-object-retention --bucket my-backups-2024 \
    --key "jetbackup5/2024-09-30/backup.tar.gz" --output json

The response includes Mode (GOVERNANCE or COMPLIANCE) and RetainUntilDate. Their presence confirms that Object Lock is active.

Using Wasabi’s Console

Open the bucket in the Wasabi console, select an uploaded backup file, and view the Object Lock tab. The mode and retention date should be displayed.

Step 6 – Adjust Retention Policies and Test Ransomware Resilience

Align the retention period with your backup rotation strategy. For example:

• Daily backups – retain 7 days
• Weekly backups – retain 30 days
• Monthly backups – retain 90 days

JetBackup lets you set different retention periods per schedule; the values are passed directly to the storage provider.

To test the protection:

1. Identify a backup object in the bucket.
2. Attempt to delete it with the CLI:
   aws s3 rm s3://my-backups-2024/jetbackup5/2024-09-30/backup.tar.gz
3. The command should fail with an AccessDenied error, confirming that the lock is enforced.

If the server’s root account is compromised, the attacker cannot delete or overwrite the locked objects, giving you a reliable restore point.

Best Practices and Common Pitfalls

• Enable versioning on the bucket in addition to Object Lock. Versioning adds an extra safeguard if a lock is inadvertently omitted.
• Use a dedicated IAM user with the minimum required permissions. Avoid using root credentials.
• Audit the bucket’s lock status regularly, especially after adding new backup schedules.
• Switching from Governance to Compliance is one‑way; Compliance cannot be lowered later.
• When using Wasabi, ensure the endpoint URL matches the selected region to prevent authentication errors.

Conclusion

Connecting JetBackup 5 to an S3‑compatible storage service with Object Lock adds a strong, storage‑level defense against ransomware. By creating a bucket with Object Lock enabled, installing and configuring the AWS CLI, and setting up a JetBackup destination that includes the lock mode and retention period, you make backup files immutable for the time you specify. This approach works with both Amazon S3 and Wasabi and is applicable to the common Linux distributions used for cPanel servers. Implementing these safeguards helps you meet compliance requirements and ensures that your customers’ data remains recoverable, regardless of the threats you face.