How to Configure Immutable Backups on a Dedicated Server to Prevent Ransomware

The Architectural Choice: Cloud Storage vs. A Secondary Dedicated Server

When setting up immutable backups (S3 Object Lock), you have two primary infrastructure paths:

• Third-Party Cloud Storage (e.g., AWS S3, Wasabi): You send your backups to a public cloud provider. While effective, you are charged per gigabyte of storage and often face unpredictable "egress fees" when you need to download your data for a restoration.

• A Secondary Dedicated Backup Server (Recommended): You provision a second dedicated server entirely isolated from your primary web/database server. By installing MinIO (a high-performance, self-hosted S3-compatible storage server), you can enable native Object Lock on your own hardware.

Why the Secondary Server Route Wins: By hosting your own backup server, you get a flat monthly rate with unlimited traffic. You maintain 100% data sovereignty, eliminate unpredictable cloud storage bills, and benefit from raw dedicated hardware performance during critical disaster recovery operations.

Prerequisites

• Primary Dedicated Server: The Linux server (Ubuntu 22.04/24.04) running your applications that needs to be backed up.

• Secondary Dedicated Server (Backup Target): A separate Linux server with ample storage to act as the immutable vault.

• Root or Sudo Access: Administrative privileges on both servers.

• Docker: Installed on the secondary backup server.

Step-by-Step Configuration Guide

Step 1: Deploy MinIO on the Backup Dedicated Server

Log in to your Secondary Dedicated Server (the backup target) via SSH. We will deploy MinIO using Docker, as it is the cleanest and most reliable method.
First, ensure Docker is installed:

 
sudo apt update
sudo apt install docker.io -y

Next, create a directory to house your backup data on the large storage drive:

 
sudo mkdir -p /mnt/backup_data

Now, launch the MinIO server container. Replace StrongAdminUser and SuperSecretPassword with highly secure credentials:

 
sudo docker run -d -p 9000:9000 -p 9001:9001 --name minio \
  -v /mnt/backup_data:/data \
  -e "MINIO_ROOT_USER=StrongAdminUser" \
  -e "MINIO_ROOT_PASSWORD=SuperSecretPassword" \
  minio/minio server /data --console-address ":9001"

Step 2: Configure Object Lock (The Immutability Engine)

Open your web browser and navigate to the MinIO web console: http://<BACKUP_SERVER_IP>:9001.

• Log in using the root credentials defined previously.

• In the left-hand menu, navigate to Buckets and click Create Bucket.

• Name your bucket (e.g., primary-server-backups).

• CRITICAL STEP: Toggle the switches to enable Versioning and Object Locking. (You cannot enable Object Lock after the bucket is created). Click Create Bucket.

• Click on your newly created bucket, navigate to the Summary or Object Lock settings.

• Set the Retention Mode to Compliance.

• Set the Validity duration (e.g., 14 Days). Click Save.

(Note: In Compliance mode, no user or administrator can overwrite or delete the backup files until the 14-day timer expires).

Step 3: Generate Access Keys

To follow the Principle of Least Privilege, we must create a dedicated API key for the primary server.

• In the MinIO dashboard, navigate to Access Keys and click Create access key.

• MinIO will generate an Access Key and a Secret Key.

• Copy these keys to a secure notepad; you will need them on the primary server.

Step 4: Install Restic on the Primary Dedicated Server

Log out of the backup server and SSH into your Primary Dedicated Server. We use Restic because it deduplicates data and encrypts everything locally via AES-256 before sending it to the MinIO server.

 
sudo apt update
sudo apt install restic -y

Verify the installation

 
restic version

Step 5: Initialize the Immutable Repository

You must initialize the Restic repository within your MinIO bucket. First, set your environment variables so Restic knows where to connect.

Replace the placeholders with your actual MinIO IP, Bucket Name, and Access Keys.

 
export AWS_ACCESS_KEY_ID="your_minio_access_key"
export AWS_SECRET_ACCESS_KEY="your_minio_secret_key"
export RESTIC_REPOSITORY="s3:http://<BACKUP_SERVER_IP>:9000/primary-server-backups"
export RESTIC_PASSWORD="generate_a_very_strong_encryption_password"

Important: Store the RESTIC_PASSWORD in a secure, offline password manager. If you lose it, your backups are permanently inaccessible.

 
restic init

Step 6: Execute the Backup and Automate

To run your first backup (for example, backing up the /var/www web directory and /etc configs), execute:

 
restic backup /var/www /etc

To automate this, create a simple bash script:

 
sudo nano /usr/local/bin/immutable_backup.sh 

Paste the following, updating the variables accordingly

 
#!/bin/bash
export AWS_ACCESS_KEY_ID="your_minio_access_key"
export AWS_SECRET_ACCESS_KEY="your_minio_secret_key"
export RESTIC_REPOSITORY="s3:http://:9000/primary-server-backups"
export RESTIC_PASSWORD="your_secure_restic_password"

# Perform the backup
/usr/bin/restic backup /var/www /etc /home

Make it executable

 
sudo chmod +x /usr/local/bin/immutable_backup.sh

Finally, open your crontab (sudo crontab -e) and schedule it to run daily at 2:00 AM

 
0 2 * * * /usr/local/bin/immutable_backup.sh >> /var/log/restic_backup.log 2>&1

You now have a fully functional, ransomware-proof immutable backup system running on your own infrastructure.