TL;DR: Restic is the gold-standard open-source backup tool for Linux servers. Pair it with SILO S3 — which is 50% cheaper than AWS S3, includes a built-in CDN at no extra cost, is ultra-fast by default, and keeps your backups 100% private with end-to-end encryption — and you have the most powerful, cost-effective server backup setup available in 2026. This guide gets you fully automated in under 15 minutes.
Table of Contents
- Why SILO S3 Is the Best Backup Destination for Linux Servers
- What Is Restic?
- Prerequisites
- Step 1 — Create Your SILO S3 Bucket & API Keys
- Step 2 — Install Restic on Linux
- Step 3 — Configure SILO S3 Credentials
- Step 4 — Initialize the Restic Repository on SILO S3
- Step 5 — Run Your First Backup
- Step 6 — Verify & Restore From Backup
- Step 7 — Automate Backups with Cron
- Advanced: Retention Policies, Snapshots & Pruning
- SILO S3 vs AWS S3 vs Backblaze B2 for Server Backups
- FAQ
- Conclusion
Why SILO S3 Is the Best Backup Destination for Linux Servers in 2026 {#why-silo}
Choosing the right offsite backup destination is one of the most important infrastructure decisions you can make. Your backup storage needs to be reliable, fast to restore from, affordable at scale, and completely private. Most popular S3 providers fail at least one of these — SILO S3 nails all four.
50% Cheaper Than S3 Storage Giants
Server backups are data-heavy. Databases, logs, configs, and application data add up fast — and so does your cloud storage bill if you’re on AWS S3, Google Cloud Storage, or Azure Blob.
SILO S3 storage starts at $0.0036/GB per month with egress at $0.0063/GB — compared to AWS S3’s $0.023/GB storage and $0.09/GB egress. For a team running 5 TB of backups with monthly restores:
| Provider | Monthly Storage (5 TB) | Egress (500 GB restore) | Total/Month |
|---|---|---|---|
| AWS S3 | $115 | $46 | ~$161 |
| Backblaze B2 | $30 | $5 | ~$35 |
| SILO S3 | $18 | $3.15 | ~$21 |
At scale, SILO S3 saves you hundreds — sometimes thousands — of dollars per year compared to the S3 giants. That’s budget you can redirect toward actual infrastructure.
Built-in CDN — No Need to Pay Extra
When a server goes down and you need to restore fast, download speed matters. SILO’s globally distributed architecture means your backup data is spread across multiple nodes worldwide — delivering CDN-level restore speeds without paying for a separate CDN service.
AWS users pay extra for CloudFront to get fast global delivery. With SILO, it’s baked in — zero configuration, zero extra cost.
Ultra Fast — Designed for Speed at Scale
SILO uses erasure coding across 100 shards — only 16 are needed to reconstruct any file — and always fetches from the fastest available nodes in parallel. This means:
- Uploads are fast — parallel writes across distributed nodes
- Restores are fast — no bottleneck on a single region or slow peer
- Large backup sets are handled gracefully — multi-part, chunked transfers work natively with Restic’s deduplication model
100% Private — Encryption You Actually Control
Server backups are among the most sensitive data you’ll ever store. SILO S3 is built on a zero-trust architecture — nodes that store your data physically cannot read it:
- End-to-end encryption by default — data is encrypted before it leaves your server
- Unique key per object — a breach of one file exposes nothing else
- User-controlled access — no third party can access your data without your credentials
And since Restic adds its own client-side AES-256 encryption layer on top, your backups are protected twice — once by Restic before upload, and once by SILO S3 at the infrastructure level.
What Is Restic? {#what-is-restic}
Restic is a modern, open-source backup program written in Go. It is widely considered the best backup tool for Linux servers due to its speed, simplicity, and security model.
Key reasons sysadmins choose Restic:
- Deduplication — only stores changed data chunks, saving enormous amounts of storage space
- Client-side AES-256 encryption — backups are encrypted before they leave your server; your storage provider never sees plaintext
- Native S3 support — works with any S3-compatible backend, including SILO S3
- Snapshots — each backup is a point-in-time snapshot, making it easy to restore to any previous state
- Incremental by design — after the initial backup, only changed data is uploaded
- Pruning & retention policies — automatically remove old backups based on rules you define
- Fast restore — retrieve specific files or full snapshots without downloading everything
Restic treats SILO S3 as a native backend via the s3 repository type — no wrappers, no plugins, no workarounds.
Prerequisites {#prerequisites}
Before you begin, make sure you have:
- A SILO S3 account — Sign up at ap.silos3.com (25 GB free for 30 days)
- A SILO S3 bucket created for your backups
- Your SILO S3 Access Key ID and Secret Access Key
- SILO S3 endpoint:
https://nexus.silosharehub.com - A Linux server (Ubuntu, Debian, CentOS, RHEL, Arch — any distro works)
-
sudo/ root access on the server - Basic familiarity with the Linux command line
Step 1 — Create Your SILO S3 Bucket & API Keys {#step1}
1.1 — Log into Your SILO Account
Go to https://ap.silos3.com and sign in.
1.2 — Create a Dedicated Backup Bucket
It’s best practice to use a dedicated bucket for backups, separate from any other data.
- Navigate to Storage → Buckets
- Click Create Bucket
- Name it something clear, like
server-backupsorprod-restic-repo - Leave the region as default (SILO distributes globally automatically)
- Click Create
Tip: Use a separate bucket per server or environment (e.g.,
web01-backups,db01-backups). This makes retention management and access control much cleaner.
1.3 — Generate API Credentials
- Go to Account → API Keys
- Click Generate New Key
- Save your:
- Access Key ID
- Secret Access Key (shown only once — copy it now!)
- Your S3 endpoint is:
https://nexus.silosharehub.com
Step 2 — Install Restic on Linux {#step2}
Ubuntu / Debian
sudo apt update && sudo apt install -y restic
CentOS / RHEL / Fedora
sudo dnf install -y restic
# or for older CentOS:
sudo yum install -y restic
Arch Linux
sudo pacman -S restic
Universal (Latest Binary — Recommended for Production)
Always pull the latest stable binary directly from the official release:
restic self-update
# or on a fresh install:
curl -fsSL https://github.com/restic/restic/releases/latest/download/restic_linux_amd64.bz2 \
| bunzip2 > /usr/local/bin/restic
chmod +x /usr/local/bin/restic
Verify Installation
restic version
Expected output:
restic 0.17.x compiled with go1.22.x on linux/amd64
Step 3 — Configure SILO S3 Credentials {#step3}
Restic reads S3 credentials from environment variables. The cleanest way to manage this on a server is a dedicated credentials file that you source before running Restic.
3.1 — Create a Secure Environment File
sudo mkdir -p /etc/restic
sudo nano /etc/restic/silo-s3.env
Add the following contents:
# SILO S3 Credentials
export AWS_ACCESS_KEY_ID="YOUR_SILO_ACCESS_KEY_ID"
export AWS_SECRET_ACCESS_KEY="YOUR_SILO_SECRET_ACCESS_KEY"
# Restic repository on SILO S3
# Format: s3:ENDPOINT/BUCKET-NAME
export RESTIC_REPOSITORY="s3:https://nexus.silosharehub.com/server-backups"
# Restic encryption password (use a strong, unique password!)
export RESTIC_PASSWORD="YOUR_STRONG_RESTIC_PASSWORD"
Security: Lock down this file immediately — it contains your credentials and encryption password.
sudo chmod 600 /etc/restic/silo-s3.env
sudo chown root:root /etc/restic/silo-s3.env
3.2 — Load the Credentials
source /etc/restic/silo-s3.env
Note on Path Style: Restic uses path-style S3 URLs natively when you provide a full custom endpoint in the format
s3:https://nexus.silosharehub.com/bucket-name. This is exactly how SILO S3 expects requests — no additional flags needed.
Step 4 — Initialize the Restic Repository on SILO S3 {#step4}
This is a one-time step that prepares your SILO S3 bucket as a Restic repository.
source /etc/restic/silo-s3.env
restic init
Expected output:
created restic repository a1b2c3d4e5 at s3:https://nexus.silosharehub.com/server-backups
Please note that knowledge of your password is required to access
the repository. Losing your password means that your backed up
data cannot be recovered.
Store your Restic password somewhere safe — in a password manager, separate from the server. If you lose it, your backup data is unrecoverable. That’s what true encryption means.
Step 5 — Run Your First Backup {#step5}
Back Up a Single Directory
source /etc/restic/silo-s3.env
restic backup /var/www --verbose
Back Up Multiple Directories at Once
source /etc/restic/silo-s3.env
restic backup /etc /var/www /home /opt --verbose
Back Up with Exclusions
Skip cache files, temp files, and logs you don’t need:
source /etc/restic/silo-s3.env
restic backup /var/www \
--exclude="*.log" \
--exclude="*/cache/*" \
--exclude="*/tmp/*" \
--verbose
Back Up a MySQL / PostgreSQL Database Dump
Always dump your database first, then back up the dump file:
# MySQL
mysqldump -u root -p --all-databases > /tmp/db-backup.sql
# PostgreSQL
pg_dumpall -U postgres > /tmp/db-backup.sql
# Then back up the dump to SILO S3
source /etc/restic/silo-s3.env
restic backup /tmp/db-backup.sql --tag database --verbose
# Clean up the local dump
rm /tmp/db-backup.sql
Sample Output of a Successful Backup
open repository
lock repository
load index files
start scan on [/var/www]
start backup on [/var/www]
Files: 1842 new, 0 changed, 0 unmodified
Dirs: 214 new, 0 changed, 0 unmodified
Data Blobs: 1801 blobs 0.000 MiB
Tree Blobs: 215 blobs 0.000 MiB
Added to the repository: 512.345 MiB (423.112 MiB stored)
snapshot 9f3a1b2c saved
Step 6 — Verify & Restore From Backup {#step6}
List All Snapshots
source /etc/restic/silo-s3.env
restic snapshots
Output:
ID Time Host Tags Paths
----------------------------------------------------------------------
9f3a1b2c 2026-06-08 02:00:01 web01 /var/www /etc
a4d7e8f1 2026-06-07 02:00:01 web01 /var/www /etc
Verify Repository Integrity
Run this regularly to confirm your backups are intact:
source /etc/restic/silo-s3.env
restic check
Restore a Full Snapshot
source /etc/restic/silo-s3.env
restic restore 9f3a1b2c --target /restore/
Restore a Specific File or Folder
No need to restore everything — Restic lets you pull individual files:
source /etc/restic/silo-s3.env
restic restore latest --target /restore/ --include /var/www/html/wp-config.php
Browse a Snapshot Like a Filesystem (Mount)
source /etc/restic/silo-s3.env
mkdir /mnt/restic-snapshot
restic mount /mnt/restic-snapshot &
ls /mnt/restic-snapshot/snapshots/latest/var/www/
This lets you copy individual files out of any snapshot without a full restore — a massive time-saver during incident recovery.
Step 7 — Automate Backups with Cron {#step7}
7.1 — Create a Backup Script
sudo nano /usr/local/bin/restic-backup.sh
#!/bin/bash
# Load SILO S3 credentials and Restic config
source /etc/restic/silo-s3.env
LOG_FILE="/var/log/restic-backup.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')
echo "[$DATE] Starting Restic backup to SILO S3..." >> "$LOG_FILE"
# Back up critical directories
restic backup \
/etc \
/var/www \
/home \
/opt \
--exclude="*.log" \
--exclude="*/cache/*" \
--exclude="*/tmp/*" \
--tag automated \
>> "$LOG_FILE" 2>&1
# Apply retention policy (keep last 7 daily, 4 weekly, 6 monthly)
restic forget \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
--prune \
>> "$LOG_FILE" 2>&1
echo "[$DATE] Backup complete." >> "$LOG_FILE"
Make it executable:
sudo chmod +x /usr/local/bin/restic-backup.sh
7.2 — Schedule with Cron
sudo crontab -e
Add this line to run the backup every night at 2:00 AM:
0 2 * * * /usr/local/bin/restic-backup.sh
7.3 — (Optional) systemd Timer Alternative
For production servers, a systemd timer is more robust than cron:
sudo nano /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic Backup to SILO S3
After=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh
sudo nano /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run Restic backup daily at 2AM
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
[Install]
WantedBy=timers.target
Enable and start:
sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl list-timers restic-backup.timer
Advanced: Retention Policies, Snapshots & Pruning {#advanced}
Retention Policy Explained
Restic’s forget command removes snapshots based on rules. Always combine with --prune to actually free the storage:
source /etc/restic/silo-s3.env
restic forget \
--keep-last 3 \ # Always keep the last 3 snapshots
--keep-daily 7 \ # Keep 1 snapshot per day for the last 7 days
--keep-weekly 4 \ # Keep 1 snapshot per week for the last 4 weeks
--keep-monthly 12 \ # Keep 1 snapshot per month for the last 12 months
--keep-yearly 3 \ # Keep 1 snapshot per year for the last 3 years
--prune
Tag Your Backups for Easy Filtering
# Web server backup
restic backup /var/www --tag webserver --tag production
# Database backup
restic backup /tmp/db.sql --tag database --tag production
# List only production snapshots
restic snapshots --tag production
Bandwidth-Limited Backup (For Low-Bandwidth Servers)
restic backup /var/www --limit-upload 20000 # limit to ~20 MB/s upload
Check Backup Health Weekly
Add this to a separate weekly cron job:
0 6 * * 0 source /etc/restic/silo-s3.env && restic check >> /var/log/restic-check.log 2>&1
SILO S3 vs AWS S3 vs Backblaze B2 for Server Backups {#comparison}
| Feature | SILO S3 | AWS S3 | Backblaze B2 | Wasabi |
|---|---|---|---|---|
| Storage Price/GB/mo | $0.0036 | $0.023 | $0.006 | $0.0068 |
| Egress Price/GB | $0.0063 | $0.09 | $0.01 | $0.00 (capped) |
| Built-in CDN | ||||
| End-to-End Encryption | ||||
| Restic Compatible | ||||
| Multi-Region Default | ||||
| Zero-Trust Privacy | ||||
| Decentralized | ||||
| 5 TB/mo Backup Cost | ~$21 | ~$161 | ~$35 | ~$34 |
| Free Tier | 25 GB / 30 days | 5 GB / 12 months | 10 GB | No |
For server backups specifically: SILO S3’s built-in multi-region distribution means your disaster recovery scenario (region goes down) is handled automatically — something AWS S3 requires separate configuration and extra cost to achieve.
Frequently Asked Questions {#faq}
Q: What Restic repository format do I use for SILO S3?
Use the s3: prefix with the full SILO endpoint and bucket name: s3:https://nexus.silosharehub.com/your-bucket-name. Set this as RESTIC_REPOSITORY in your environment file.
Q: Does Restic work with SILO S3’s path-style addressing?
Yes. When you provide a full custom endpoint in Restic’s s3:https://... format, Restic constructs path-style URLs automatically — which is exactly what SILO S3 requires. No extra flags are needed for Restic (unlike Rclone, which requires force_path_style = true).
Q: Is the data double-encrypted with Restic + SILO S3?
Yes. Restic encrypts all backup data with AES-256 client-side before uploading, so your data is already encrypted when it reaches SILO S3. SILO then applies its own end-to-end encryption at the infrastructure level. Both layers are completely independent.
Q: How do I back up a running MySQL database without downtime?
Use mysqldump with the --single-transaction flag to take a consistent snapshot without locking tables: mysqldump --single-transaction -u root -p mydb > /tmp/mydb.sql, then back up /tmp/mydb.sql with Restic.
Q: How long does the first backup take?
The initial backup uploads everything. Subsequent backups are incremental — Restic only uploads changed chunks, which are typically much smaller and faster. A 10 GB initial backup might take a few minutes on a decent connection; daily incrementals on the same data often take seconds.
Q: Can I back up multiple servers to the same SILO S3 bucket?
Yes, but use a unique Restic repository path per server: s3:https://nexus.silosharehub.com/server-backups/web01, s3:https://nexus.silosharehub.com/server-backups/db01. This keeps snapshots isolated and makes restores cleaner.
Q: What happens if SILO S3 nodes go offline during a backup?
SILO’s erasure coding distributes your data across 100 shards — only 16 are needed to reconstruct any file. If some nodes go offline mid-backup, SILO automatically reroutes to healthy nodes. Your backup either completes normally or fails cleanly, and Restic can resume from where it left off on the next run.
Q: How do I test that my backups actually work?
Run restic check regularly to verify repository integrity. More importantly, do a test restore to a staging server periodically — this is the only way to be certain your backups are truly recoverable. A backup you’ve never tested is not a backup you can trust.
Conclusion {#conclusion}
Restic + SILO S3 is the definitive Linux server backup stack for 2026. You get enterprise-grade backup tooling with a storage backend that outperforms the big cloud players on every axis that matters for backups:
50% cheaper than AWS S3, Google Cloud, and other S3 giants — keep your backup costs predictable
Built-in CDN — fast restores from anywhere, no extra service to configure or pay for
Ultra-fast — parallel distributed uploads and restores, no regional bottlenecks
100% private — zero-trust storage + Restic’s client-side AES-256 = your data is unreadable to anyone but you
And the operational setup is genuinely simple: one credentials file, one script, one cron job — and your servers are protected nightly with versioned, deduplicated, encrypted offsite backups.
Ready to protect your servers?
Sign up for SILO S3 — 25 GB Free
SILO S3 Documentation
Restic Official Documentation
Tested this setup on your server? Share your distro and backup size in the comments — we’d love to hear how it went! ![]()
Found this guide useful? Drop a
and share it with your team!
Tags: restic silo-s3 linux-backup server-backup s3-compatible object-storage tutorials devops sysadmin privacy backup-automation disaster-recovery cron systemd