Offsite Backups to S3 or R2 with rsync and restic

By Khimananda Oli | Last reviewed: August 2026

Reliable disaster recovery requires more than local snapshots; you need verifiable, encrypted replicas stored outside your primary infrastructure. Implementing offsite backups to S3 or R2 with rsync and restic provides a cost-effective, cryptographically secure safety net against ransomware, hardware failure, and regional outages. This guide covers the exact configuration I use in production environments to ensure data integrity and rapid restoration without breaking the bank.

How do you configure offsite backups to S3 or R2 with rsync and restic?

The most common mistake engineers make is treating object storage like a traditional filesystem. While rsync excels at mirroring files between POSIX systems, it lacks native understanding of S3 APIs and cannot perform chunk-level deduplication against remote objects. In practice, you should use restic as the primary backup engine for object stores because it handles encryption, compression, and incremental snapshots natively over HTTP. Reserve rsync for pre-staging data locally or syncing between compatible filesystems before the final push to cloud storage.

Install and initialize the repository

First, install restic on your Ubuntu or RHEL server. For modern distributions in 2026, the official binary is preferred over older package manager versions to ensure compatibility with current S3 API signatures.

# Download latest restic binary
wget https://github.com/restic/restic/releases/download/v0.18.0/restic_0.18.0_linux_amd64.bz2
bzip2 -d restic_0.18.0_linux_amd64.bz2
sudo mv restic_0.18.0_linux_amd64 /usr/local/bin/restic
sudo chmod +x /usr/local/bin/restic

# Set credentials securely (never hardcode in scripts)
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key

# Initialize S3 repository
restic -r s3:s3.amazonaws.com/my-backup-bucket init

# Or initialize Cloudflare R2 repository
export AWS_ENDPOINT_URL=https://account-id.r2.cloudflarestorage.com
restic -r s3:my-r2-bucket init

During initialization, restic will prompt for a repository password. Store this password in a secure vault like HashiCorp Vault or AWS Secrets Manager—losing it means losing access to all backups permanently. I recommend reading my guide on secrets management with HashiCorp Vault for production-grade credential handling.

Create automated snapshot schedules

Manual backups fail. Automate the process using systemd timers or cron, ensuring you capture application-consistent states. Always dump databases before triggering the restic snapshot to avoid corrupt partial files.

#!/bin/bash
# /opt/scripts/backup-offsite.sh
set -euo pipefail

# Load secrets from protected file
source /etc/restic/env.sh

# Database dump first
pg_dump -Fc myapp_db > /var/backups/db/myapp_$(date +%F).dump

# Run restic backup with tags
restic -r s3:s3.amazonaws.com/my-backup-bucket \
  backup /var/www/html /var/backups/db \
  --tag production \
  --tag $(hostname) \
  --exclude-caches

# Prune old snapshots (keep last 7 daily, 4 weekly, 6 monthly)
restic -r s3:s3.amazonaws.com/my-backup-bucket \
  forget --prune \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

# Verify integrity
restic -r s3:s3.amazonaws.com/my-backup-bucket check --read-data-subset=5%

When should you choose Cloudflare R2 over AWS S3 for backups?

Cost structure dictates this decision more than technical capability. Both platforms support the S3 API, making them interchangeable from restic's perspective, but their billing models create vastly different operational expenses. If your backup strategy involves frequent restore tests, large dataset migrations, or multi-region replication, egress fees become the dominant line item.

For Nepali businesses and startups operating on tight margins, R2 often delivers 60–80% savings on active backup workloads where monthly restore testing is mandatory. However, if you require WORM (Write Once Read Many) locks for regulatory compliance or need to retain petabytes of historical data for years, S3 Glacier Deep Archive remains unmatched at $0.00099/GB. Review cloud cost optimization tactics to model your specific spend before committing.

How do you verify and restore restic backups reliably?

A backup you cannot restore is just expensive storage. Verification must be automated and periodic, not an afterthought during a crisis. Restic provides built-in integrity checking, but true confidence comes from actual restoration drills performed on isolated infrastructure.

1. Run automated health checks weekly: Use restic check --read-data-subset=10% to verify random portions of your repository without downloading everything. Schedule this via cron and alert on failure.
2. Perform monthly full restore tests: Spin up an ephemeral VM or container, restore the latest snapshot, and validate application startup. Document the time-to-recovery metric.
3. Test selective file recovery: Practice restoring individual files with restic restore latest --target /tmp/restore --include /var/www/html/config.php. This is the most common real-world scenario.
4. Validate encryption independence: Attempt a restore on a machine that has never accessed the repository before, using only the password and credentials. This confirms no hidden local state dependencies exist.

# Full restore to alternate location
restic -r s3:s3.amazonaws.com/my-backup-bucket \
  restore latest \
  --target /tmp/disaster-recovery-test \
  --verify

# Mount repository for browsing (useful for ad-hoc recovery)
restic -r s3:s3.amazonaws.com/my-backup-bucket mount /mnt/restic-fuse

# List snapshots with metadata
restic -r s3:s3.amazonaws.com/my-backup-bucket snapshots --compact

If you are running containerized applications, integrate restore validation into your CI pipeline. My article on containerizing Laravel apps demonstrates patterns for ephemeral test environments that work well for backup verification.

What security practices protect offsite backup repositories?

Backups are high-value targets. They contain complete copies of your data, often with weaker access controls than production systems. Apply defense-in-depth principles identical to what you would use for live infrastructure.

• Enable server-side encryption: Both S3 and R2 support SSE-S3 by default. For sensitive workloads, use SSE-KMS with customer-managed keys to maintain cryptographic sovereignty.
• Apply least-privilege IAM policies: Create dedicated users/roles with permissions scoped to a single bucket prefix. Never reuse production credentials for backup operations.
• Implement immutability where possible: Enable S3 Object Lock in compliance mode or R2's legal hold feature to prevent deletion even if credentials are compromised. This is critical ransomware protection.
• Separate network paths: Route backup traffic through VPC endpoints or private links to avoid exposing data to the public internet. See VPC networking fundamentals for proper architecture.
• Audit access logs: Enable S3 access logging or R2 audit logs and forward them to your SIEM. Alert on unexpected GET/LIST operations outside scheduled backup windows.

Securing Your Offsite Backups to S3 or R2 with rsync and restic

Implementing offsite backups to S3 or R2 with rsync and restic transforms fragile local copies into resilient, auditable disaster recovery assets. Start with restic for native S3/R2 support, choose your storage backend based on restore frequency and compliance needs, automate verification relentlessly, and wrap everything in layered security controls. The goal is not just having backups—it is knowing they will work when everything else fails. If you need help designing a compliant backup architecture or auditing your existing setup, reach out to discuss your infrastructure.