How to Back Up Multiple VPS Instances from One Central Location

知識庫

Managing backups individually across several servers doesn't scale well. This guide covers pulling backups from multiple VPS instances into one centralized, easier-to-manage location.

Why Centralize Backups

One place to verify all backups completed successfully, rather than checking each server individually
Simplifies off-site storage — sync from one central location instead of each server separately
Easier retention policy management applied consistently across all servers

Architecture: Pull vs Push

Approach	How It Works	Consideration
Push	Each server sends its backup to the central location	Simpler per-server setup, but a compromised server could also compromise the backup destination credentials
Pull	The central backup server connects out to each source server to retrieve data	Source servers don't need destination credentials, generally considered more secure

Setting Up a Pull-Based Central Backup Server

Step 1 — Provision a Dedicated Backup Server

A modest VPS is usually sufficient, sized based on total backup storage needs across all source servers.

Step 2 — Set Up SSH Key Access from the Backup Server to Each Source

ssh-keygen -t ed25519 -f ~/.ssh/backup_key
ssh-copy-id -i ~/.ssh/backup_key.pub deploy@SOURCE_SERVER_1_IP
ssh-copy-id -i ~/.ssh/backup_key.pub deploy@SOURCE_SERVER_2_IP

Step 3 — Create a Pull Script for Each Source Server

sudo nano /usr/local/bin/pull-backups.sh

#!/bin/bash
TIMESTAMP=$(date +%F)
BACKUP_ROOT="/backups"

SERVERS=("server1.example.com" "server2.example.com" "server3.example.com")

for SERVER in "${SERVERS[@]}"; do
    mkdir -p "$BACKUP_ROOT/$SERVER/$TIMESTAMP"
    rsync -avz -e "ssh -i /root/.ssh/backup_key" \
      "deploy@$SERVER:/var/backups/" \
      "$BACKUP_ROOT/$SERVER/$TIMESTAMP/"
done

Step 4 — Ensure Each Source Server Has Its Own Backups Ready to Pull

Each individual server should still run its own local backup process (database dumps, etc.) as covered in How to Set Up Automated VPS Backups — the central server then pulls these already-created backup files, rather than performing the dump itself remotely.

Step 5 — Schedule the Pull

sudo crontab -e

0 4 * * * /usr/local/bin/pull-backups.sh >> /var/log/central-backup.log 2>&1

Step 6 — Sync the Central Repository Off-Site

The central backup server itself should still follow the 3-2-1 rule — sync its aggregated backups to object storage:

aws s3 sync /backups s3://your-backup-bucket/ --profile backup

Restricting Source Server Access

On each source server, restrict SSH access for the backup key to only the specific commands needed (using SSH's authorized_keys command= restriction), limiting what a compromised backup server could do if it were ever breached.

Monitoring the Central Backup Process

Set up alerting if any source server's pull fails — a silent failure defeats the purpose of centralization:

if [ $? -ne 0 ]; then
    echo "Backup pull failed for $SERVER" | mail -s "ALERT: Backup Failure" [email protected]
fi

Common Errors

SSH key authentication fails from the central server — verify the public key was correctly added to each source server's authorized_keys.

Central server becomes a bottleneck/single point of failure — ensure the central server's own backups are also verified and stored off-site, following the same rigor as any other critical system.

Best Practices

Use pull-based architecture where practical, for better security isolation
Restrict backup SSH keys to minimal necessary permissions on source servers
Don't let the central backup server itself become an unbacked-up single point of failure

Continue Reading

Browse more articles in Backup & Disaster Recovery.

知識庫

分類

分類