Why use a dedicated server for backup and disaster recovery?
A backup server stores copies of operating systems, databases, virtual machines, application files, media, and configuration data so services can be restored after hardware failure, ransomware, accidental deletion, or a regional outage. A dedicated server is useful when backup jobs run continuously, the protected data set is large, or restore speed matters.
Unlike a shared storage plan, a bare-metal server gives your backup workload reserved CPU, memory, disk controllers, network capacity, and storage bays. That isolation helps prevent a neighbor's workload from slowing a backup window or a large restore. It also allows you to choose RAID, filesystem, encryption, snapshot, and retention policies suited to your environment.
A dedicated server is not automatically a disaster-recovery plan. A single server can fail, be compromised, or be affected by the same fire, flood, power event, or network outage as the primary systems. Use the 3-2-1 rule: keep at least three copies of data, on two different storage media, with one copy off-site. For ransomware resistance, make at least one copy immutable or disconnected from normal administrator credentials.
When a VPS is enough
A VPS can handle a small backup repository when the data set is below roughly 500 GB, daily changes are modest, and recovery-time objectives are measured in hours rather than minutes. A 2 to 4 vCPU VPS with 4 to 8 GB RAM and 500 GB to 1 TB of attached storage can receive database dumps, website archives, Git repositories, and encrypted workstation backups.
Choose a VPS when you need a low-cost secondary copy, a temporary staging repository, or a backup coordinator that sends data to object storage. It is also suitable for running restic, Borg, UrBackup, or a backup management interface while the large repository resides elsewhere.
Check the provider's storage and bandwidth policy before relying on a VPS. Some plans limit disk I/O, charge for outbound traffic, or use shared storage with inconsistent latency. A VPS may also lack enough local disk capacity for multiple full backups and retention points.
When to move to dedicated or bare metal
- Large repositories: Move to dedicated hardware when protected data approaches 1 to 2 TB and you need several full, incremental, or synthetic-full restore points.
- High daily change rates: Databases, video production, mail stores, and virtual machines can generate hundreds of gigabytes of changes per day. Dedicated disks provide more predictable write performance.
- Short recovery targets: Restoring 5 TB over a modest connection can take many hours. A local 10 Gbps network and dedicated storage reduce restore time, although disk throughput and source-system speed still matter.
- Isolation requirements: Compliance, security, and ransomware controls may require dedicated access, separate credentials, encrypted volumes, and a controlled hardware environment.
- Multiple clients or systems: A dedicated repository is easier to partition for production servers, development environments, employee devices, and disaster-recovery replicas.
Recommended dedicated backup server specifications
CPU and memory
Backup software usually does not need as much CPU as a database server, but compression, encryption, deduplication, catalog indexing, and parallel jobs can consume several cores. Use 4 vCPU and 8 GB RAM for a small repository, 8 physical cores and 32 GB RAM for a medium repository, and 16 physical cores with 64 GB RAM for large repositories or many concurrent jobs.
Memory should support the backup catalog, filesystem cache, deduplication metadata, and monitoring agents. ZFS users should budget additional RAM for caching and avoid treating cache as a substitute for adequate disk. ECC memory is preferable because silent memory errors can corrupt data during backup or restore operations.
Storage layout
Capacity planning must include usable RAID capacity, filesystem overhead, retention, and growth. RAID is not a backup; it protects availability when a disk fails. Use RAID1 for a small repository, RAID6 for larger arrays, and a hot spare where practical. RAID10 can provide higher write performance but uses half of raw capacity.
Use enterprise HDDs for economical sequential backup capacity and SSD or NVMe storage for the operating system, backup catalog, indexes, databases, and frequently accessed restore points. A small NVMe system volume can also hold temporary metadata, but do not place the only copy of backup data on it.
Estimate storage with this formula: required capacity equals the initial data set plus daily change multiplied by retention days, then add space for full backups, snapshots, metadata, and growth. Keep at least 20 percent free space on the filesystem so compaction, snapshots, and restores do not fail unexpectedly.
Network and bandwidth
For small environments, a 1 Gbps port and 5 TB of monthly transfer can be sufficient. Medium repositories benefit from a 1 or 10 Gbps port and at least 20 TB of monthly transfer. Large repositories should use 10 Gbps connectivity where the source servers and storage array can sustain it, with bandwidth sized for full replication plus restores.
Calculate transfer needs from the changed data, not just the original data set. A 10 TB repository with 300 GB of daily changes generates about 9 TB of changed data in a 30-day month before deduplication and compression. Keep an allowance for verification, off-site replication, and emergency restores.
Confirm whether the provider counts inbound, outbound, or both directions. A backup may be mostly inbound, while disaster recovery and cloud replication can create substantial outbound traffic.
For up to 2 TB of protected data use a 4 vCPU / 8 GB / 4 TB mirrored-HDD server; at 10 TB move to 8 cores / 32 GB / 16 TB RAID6; for 50 TB use 16 cores / 64 GB / 72 TB RAID6 with 10 Gbps networking.
| Protected data set | vCPU or cores | RAM | Disk | Monthly bandwidth |
|---|---|---|---|---|
| Up to 2 TB | 4 vCPU | 8 GB | 2 × 4 TB HDD RAID1, 240 GB NVMe OS disk | 5 TB |
| 2–10 TB | 8 physical cores | 32 GB | 6 × 4 TB HDD RAID6, 480 GB NVMe metadata disk | 20 TB |
| 10–50 TB | 16 physical cores | 64 GB | 8 × 12 TB HDD RAID6, 960 GB NVMe catalog disk | 60 TB |
Backup software and architecture
Linux administrators commonly use Borg or Restic for encrypted, deduplicated repositories. Rsync is useful for file mirrors but should be combined with snapshots, versioning, or a backup tool because a deletion can otherwise propagate immediately. Veeam, Nakivo, and similar platforms are often chosen for virtual machines and Windows environments. Native database tools should create consistent database backups before files are copied.
Separate backup traffic from public application traffic when possible. Use a private VLAN, WireGuard tunnel, site-to-site VPN, or firewall-restricted network. Permit backup connections only from known source addresses. Do not expose an administrative panel or SSH service to the entire internet.
Keep the backup repository logically separate from production credentials. A compromised web server should not be able to delete every backup. Use a dedicated backup account with append-only or restricted permissions, separate SSH keys, multi-factor authentication for management interfaces, and an offline or immutable destination.
Step-by-step setup
1. Install and harden the operating system
Install a supported Linux distribution on the NVMe system disk, apply updates, create a non-root administrator, and disable password authentication after testing SSH keys.
2. Identify and format the data array
Confirm disk names before formatting. The following example creates an XFS filesystem on an already configured RAID device; replace /dev/md0 only after verifying it with lsblk.
lsblk -o NAME,SIZE,TYPE,MODEL
sudo mkfs.xfs -f /dev/md0
sudo mkdir -p /srv/backups
sudo mount /dev/md0 /srv/backups3. Make the mount persistent
Use the filesystem UUID rather than a device name so the repository mounts correctly after a reboot.
sudo blkid /dev/md0
sudo nano /etc/fstab
# Add: UUID=YOUR_UUID /srv/backups xfs defaults,noatime 0 2
sudo mount -a
df -h /srv/backups4. Create a restricted backup account
Do not run routine backup transfers as root. Create a service account and limit its access to the repository.
sudo useradd --create-home --shell /usr/sbin/nologin backup
sudo chown -R backup:backup /srv/backups
sudo chmod 700 /srv/backups5. Install a backup tool
For a simple encrypted repository, install Borg from the distribution package and initialize it with a strong repository passphrase stored in a password manager.
sudo apt update && sudo apt install -y borgbackup
sudo -u backup borg init --encryption=repokey-blake2 /srv/backups/repository6. Create and test a backup job
Run a test backup, exclude caches and temporary files, and inspect the archive before automating it.
sudo -u backup borg create --stats /srv/backups/repository::{now} /etc /home
sudo -u backup borg list /srv/backups/repository7. Add retention and scheduled pruning
Retention should match business requirements. The example keeps seven daily, four weekly, and six monthly archives. Adjust it after reviewing storage consumption.
sudo -u backup borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/backups/repository
sudo crontab -u backup -e8. Verify recovery and replicate off-site
Schedule integrity checks and perform real file restores. Copy encrypted repositories to a second location using a separate credential. A backup job that completes successfully but has never been restored is not proven protection.
sudo -u backup borg check --verify-data /srv/backups/repository
sudo -u backup borg extract /srv/backups/repository::ARCHIVE etc/hostnamePerformance optimization
- Use incremental and deduplicated backups: They reduce repeated reads and network transfer, but measure CPU use because compression and encryption can become bottlenecks.
- Schedule intelligently: Run full or synthetic-full jobs outside peak application hours. Stagger databases, virtual machines, and file servers instead of starting every job at midnight.
- Protect database consistency: Use PostgreSQL
pg_dump, MySQL logical dumps, SQL Server-aware agents, or filesystem snapshots coordinated with the database. Copying live database files without coordination can produce unusable backups. - Use snapshots carefully: Snapshots help create consistent restore points, but they consume capacity and do not protect against failure of the underlying array.
- Monitor I/O and network usage: Track disk latency, filesystem fullness, RAID health, CPU, memory, failed jobs, and replication lag. Alert before the repository reaches 80 percent capacity.
- Separate metadata from bulk data: An NVMe catalog or index volume can improve listing, deduplication, and restore-file selection while HDDs provide economical capacity.
- Verify archives: Run periodic checksums and test restores. Verification should cover both a small file and a complete application or virtual machine.
Common pitfalls to avoid
Using RAID as the backup
RAID6 can keep a server online after disk failures, but it cannot recover files deleted by an administrator, encrypted by ransomware, or damaged by an application bug. Maintain an independent off-site copy.
Ignoring retention and growth
A repository can fill quickly when daily database exports are retained indefinitely. Set retention by business need, calculate projected growth, and leave free capacity for compaction and emergency restores.
Allowing unrestricted deletion
If production credentials can delete the repository, an attacker who compromises production can erase recovery points. Use separate identities, append-only policies, immutable storage, and delayed deletion where supported.
Skipping restore tests
Corrupt archives, missing encryption keys, incorrect permissions, and undocumented dependencies often appear only during a recovery. Test individual files monthly and a complete service restoration at least quarterly, or according to your recovery policy.
Underestimating outbound transfer
Backups may fit within inbound transfer allowances while a disaster recovery event requires many terabytes of outbound data. Confirm port speed, transfer caps, pricing, and provider abuse controls before committing to a recovery design.
Storing encryption keys beside the backups
Encryption protects confidentiality only if keys are managed correctly. Store recovery keys in a separate password manager or key-management system, maintain an authorized recovery procedure, and test that designated staff can access them.
How to choose the right recovery design
Define a recovery point objective (RPO), which is the maximum acceptable amount of lost data, and a recovery time objective (RTO), which is the maximum acceptable downtime. Nightly backups may satisfy a 24-hour RPO but fail a 30-minute RTO. Frequent snapshots, database replication, a warm standby, or a second dedicated server may be required for stricter targets.
For websites and self-hosted applications, back up files, databases, environment variables, TLS certificates, firewall rules, and deployment configuration. For game servers, include world data and plugin configuration. For mail servers, protect mailboxes, domains, DKIM keys, user databases, and queue data. For CI/CD systems, include repositories, build artifacts, secrets references, and runner configuration.
A dedicated server is usually the best primary repository for sustained, multi-terabyte backup workloads. A VPS remains sensible for a small encrypted copy or backup controller. In both cases, pair local fast recovery with an off-site, encrypted, independently authenticated copy.