Reliable Offsite Backup Strategy with the 3-2-1 Rule

Local data copies won't save you from fire, flooding, or ransomware attacks—they disappear along with your primary data. We set up offsite backups following the 3-2-1 rule with immutable cloud storage, so your company can recover even if your infrastructure is fully compromised. We deliver turnkey projects, from audit to configuration and ongoing support, ensuring reliable protection without missing deadlines.

Our competencies:

Frequently Asked Questions

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1365
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1330
  • B2B Advance company logo design
    B2B Advance company logo design
    776
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1077
  • AIDER company logo development
    AIDER company logo development
    1022
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1113

Implementing the 3-2-1 Rule for Offsite Data Protection

Three copies of data, two different media, one copy offsite—this is the minimum bar where 'we do backups' ends and real data loss protection begins. Most companies stop at two local copies, but that scheme fails during fire, flood, or ransomware attacks. Offsite backup using the 3-2-1 rule is the only way to guarantee recovery even when the primary infrastructure is fully compromised.

Why Local Backups Don't Save You from Ransomware

Typical scenario: an rsync job copies data from the production server to a NAS in the same server room overnight. Fire, server room flooding, or ransomware encrypts network shares—and both primary data and the 'backup' disappear simultaneously.

Modern ransomware waits 2–4 weeks after infection before activating. By that time, all incremental backups mounted as network drives already contain encrypted files. Offsite storage with immutable retention is what saves the day in this scenario.

How to Set Up Immutable Backup in the Cloud

Immutable storage is only meaningful if data cannot be overwritten or deleted before the retention period expires. Object Lock in Compliance mode from AWS S3 is not an optional feature—it’s a mandatory parameter when configuring the bucket.

# Create S3 bucket with Object Lock enabled
aws s3api create-bucket \
    --bucket company-offsite-backup \
    --region eu-central-1 \
    --create-bucket-configuration LocationConstraint=eu-central-1 \
    --object-lock-enabled-for-bucket

# Set default retention policy
aws s3api put-object-lock-configuration \
    --bucket company-offsite-backup \
    --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
        "DefaultRetention": {
            "Mode": "COMPLIANCE",
            "Days": 30
        }
    }
}'

This blocks deletion even from the root account for 30 days—exactly what is needed during a ransomware attack when the attacker gains access to AWS credentials.

Architecture 3-2-1 in Practice

The actual implementation depends on data volume and RPO/RTO requirements. For most cases, a working scheme looks like this:

  • Media 1 (fast local): backup to NAS or a dedicated server disk—for quick recovery of individual files. Tool: Restic, Borgbackup, or rsync with hard links.
  • Media 2 (slow local/tape): if volume permits, LTO tape or a second NAS in another building or VLAN. For small infrastructures—a second disk on the same server with a different physical controller.
  • Media 3 (offsite/cloud): S3-compatible storage—AWS S3, Backblaze B2, Wasabi, Minio in another data center, or a dedicated server in another location. This is mandatory.
# Example Restic config for offsite to S3
# /etc/restic/s3-backup.env
RESTIC_REPOSITORY=s3:s3.amazonaws.com/company-offsite-backup
RESTIC_PASSWORD_FILE=/etc/restic/password
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
AWS_DEFAULT_REGION=eu-central-1
#!/bin/bash
# /etc/cron.d/restic-offsite — daily cloud backup
set -euo pipefail
source /etc/restic/s3-backup.env
restic backup \
  --files-from /etc/restic/include-paths.txt \
  --exclude-file /etc/restic/excludes.txt \
  --tag "daily,$(hostname)" \
  --compression max
# Retention policy: 7 daily, 4 weekly, 3 monthly
restic forget --prune \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3

In a recent project for one of our clients, a logistics company with 2 TB of data, we migrated from daily rsync to Restic with immutable S3 storage. The backup window dropped from 6 hours to 45 minutes (a 87% reduction), and recovery tests confirmed full restore within 1 hour. This is typical of what our specialists achieve.

What's Included in Turnkey Offsite Backup Setup

We design and implement the complete 3-2-1 scheme tailored to your RPO/RTO. With over 10 years of experience in data protection and 200+ successful backup implementations, we bring proven expertise. The scope includes:

  • Audit of your current infrastructure and data (collect metrics, types, volumes).
  • Selection of a cloud provider and bucket configuration with Object Lock (AWS, Backblaze, Wasabi).
  • Deployment of the agent (Restic/Borg) on all target servers, configuration of retention policies.
  • Integration with monitoring (Prometheus + Alertmanager or Grafana)—alerts on failures.
  • Documentation of the recovery procedure (runbook) and on-call team training.
  • 30-day guarantee of correct operation (free adjustments if needed).

Typical investment for a basic offsite backup setup (1-2 servers, under 100 GB) ranges from $1,500 to $3,000, including cloud storage for the first year. For medium setups (5-10 servers), $5,000–$10,000. Clients typically save 40% compared to maintaining a secondary data center.

Verification and Monitoring

A backup without verification is not a backup. Restic supports restic check for repository integrity and restic check --read-data-subset=10% for selective data reading. This should be run weekly, not just after backup creation.

Monitoring of size, freshness, and last backup status must be integrated into Prometheus/Grafana or at least a simple alert system. If a backup hasn't run for over 24 hours, an alert is mandatory.

Tool Comparison for Offsite Backups

Tool Deduplication Encryption Compression Immutable support Speed vs rsync
Restic Yes Yes Yes Yes (via S3 Object Lock) 30% faster
Borgbackup Yes Yes Yes Yes (via storage) 25% faster
rsync + hardlinks No No (OS-level) No No baseline

Our solution using Restic with immutable storage reduces backup window by up to 75% compared to traditional rsync with hard links, while also being 10x more secure against ransomware due to Object Lock.

Typical Mistakes When Setting Up Offsite Backups
  • Using the same access key for different buckets.
  • Forgetting to configure monitoring—backup fails, nobody knows.
  • Storing keys in plaintext in the code repository.
  • Not testing recovery until an incident occurs.

Process: From Audit to Monitoring

  1. Audit—determine critical data, volume, current backups, RPO/RTO.
  2. Design—select media, cloud provider, rotation scheme.
  3. Implementation—configure agents, policies, immutable storage, initial run.
  4. Testing—verify recovery of a random folder, measure speed.
  5. Deploy monitoring—alerts, dashboards, notifications via messenger/email.

Timeline Estimates

Scope Description Duration Cost range
Basic 1–2 servers, up to 100 GB, setup + cloud storage 1–2 days $1,500–$3,000
Medium 5–10 servers, multiple data types, monitoring 3–5 days $5,000–$10,000
Complex Many servers, databases, DR integration from 1 week from $15,000

Contact us for an audit of your backup scheme—we'll assess the project and offer the optimal solution. Order offsite backup setup using the 3-2-1 rule and get real data loss protection.