Dedicated Server for Backup & Disaster Recovery

When a ransomware attack encrypts your production database at 2 a.m., the only thing that matters is whether last night's backup is intact, offsite, and restorable within your promised recovery window. Cloud snapshot storage is convenient until you calculate the egress bill for a 40 TB restore, and that is precisely the moment most IT teams start pricing out a dedicated server for backup and disaster recovery. Unlike a shared backup-as-a-service tier where your retention window and throughput are dictated by someone else's multi-tenant array, a dedicated box gives you your own disks, your own network path, and a predictable bill that does not spike the month you actually need to pull data back down.

This guide walks through how to size a backup and DR server properly, which RAID levels actually make sense for backup targets versus production databases, how to architect a 3-2-1 backup strategy across two dedicated servers in different regions, and what the real monthly cost looks like once you account for storage, bandwidth, and replication.

What Is a Dedicated Backup and Disaster Recovery Server?

A dedicated backup and DR server is a physical machine leased or owned specifically to receive, store, and (when needed) restore copies of your production data. It typically runs one of three roles:

• Backup repository — a target for tools like Veeam, Bacula, BorgBackup, restic, or rsync that receives nightly or hourly incremental backups from production systems.
• Warm DR standby — a server kept in near-real-time sync with production (via replication or continuous backup) that can be promoted to production within minutes to hours.
• Cold archive target — a high-capacity, lower-performance server used purely for long-term retention (30, 90, or 365+ day copies) that is rarely touched except for compliance audits or worst-case recovery.

Many organizations run all three roles across two physical servers in separate data centers: one local, fast repository for daily operational recovery (accidentally deleted a table, need last night's copy), and one offsite server that satisfies the "3-2-1 rule" — three copies of data, on two different media types, with one copy offsite.

Sizing a Backup Server: RPO, RTO, and Storage Math

Before pricing hardware, define two numbers that drive everything else:

• RPO (Recovery Point Objective) — how much data you can afford to lose. An RPO of 15 minutes means you need near-continuous replication; an RPO of 24 hours means nightly backups are fine.
• RTO (Recovery Time Objective) — how fast you must be back online. An RTO of 1 hour rules out "restore from cold archive tape equivalent" and pushes you toward a warm standby server that can be promoted quickly.

Once RPO/RTO are set, size storage using this formula: Total capacity = full backup size + (daily change rate x retention days) + 20% overhead. For example, a 2 TB production database with a 3% daily change rate and a 30-day retention policy needs roughly 2 TB (full) + (60 GB x 30 days = 1.8 TB incrementals) + 20% overhead = about 4.6 TB of usable backup storage, before accounting for compression (backup tools typically achieve 1.5x-3x compression on database dumps, so real disk usage is often lower).

Hardware Specs That Actually Matter for Backup Servers

Storage Capacity and Drive Mix

Backup servers are storage-bound, not CPU-bound. A reasonable baseline is 4-8 bays of 4-16 TB SATA or SAS HDDs for the bulk repository, paired with a small NVMe or SSD cache tier (480 GB-1 TB) for the write-ahead log or deduplication index if your backup software uses one (Veeam's dedup engine, for example, benefits heavily from having its index on fast storage even when the backup files themselves live on spinning disk).

RAID Level Selection

RAID 6 is the standard choice for backup repositories because it tolerates two simultaneous drive failures without data loss, which matters more here than raw write speed — you are writing sequentially during backup windows, not doing random small-block transactions like a database. RAID 10 is worth the extra drive cost only if you need the array to also serve as a fast restore target for near-continuous replication (warm DR standby), since RAID 10 rebuilds faster and has better random I/O for replay operations. Avoid RAID 5 for anything above 8 TB per drive — the rebuild window on a failed 16 TB drive can exceed 24 hours, during which a second failure means total array loss.

Network Bandwidth

A 1 Gbps uplink caps your realistic transfer rate around 100-110 MB/s, meaning a 5 TB full backup takes roughly 13 hours to transfer — unacceptable if your backup window is a single overnight run. For anything beyond 2-3 TB in a nightly full backup, a 10 Gbps port is not a luxury, it is the difference between a backup job that finishes and one that runs into business hours. Incremental-forever strategies reduce this pressure significantly since only changed blocks transfer nightly, with periodic synthetic fulls built server-side.

Step-by-Step: Building a 3-2-1 Backup Architecture on Two Dedicated Servers

Step 1: Provision the Primary Repository

Deploy a Linux dedicated server (Ubuntu 24.04 LTS or AlmaLinux 9 are both solid choices) with your RAID 6 array formatted as XFS, which handles large sequential files and sparse backup archives better than ext4 at scale. Mount it at /mnt/backup01 and set up a dedicated non-root user for the backup service account.

Step 2: Configure Backup Software

For Veeam Backup & Replication, add the server as a Linux repository target via Backup Infrastructure > Backup Repositories > Add Repository > Linux, enabling "Use fast cloning" if your filesystem supports it (XFS reflink) to reduce space consumption on synthetic fulls. For an open-source stack, BorgBackup with a repository initialized via borg init --encryption=repokey-blake2 /mnt/backup01/repo gives you deduplicated, encrypted, compressed backups with minimal overhead — a typical borg create job looks like:

borg create --stats --compression zstd,6 \
  /mnt/backup01/repo::{hostname}-{now:%Y-%m-%d} \
  /var/www /etc /home --exclude-caches

Step 3: Set Up the Offsite Replica

Provision a second dedicated server in a different geographic region — pairing a primary in one metro with a DR replica in another materially reduces the odds that a regional power outage, fiber cut, or natural disaster takes out both copies simultaneously. Replicate nightly using rsync over SSH with bandwidth throttling to avoid saturating your production uplink during business hours:

rsync -avz --bwlimit=50000 -e "ssh -p 22" \
  /mnt/backup01/repo/ user@dr-server:/mnt/backup02/repo/

Step 4: Automate and Alert

Wrap every backup and replication job in a script that emails or pages your team on non-zero exit codes. A silent backup failure that goes unnoticed for three weeks is functionally identical to having no backup at all. Tools like Healthchecks.io or a simple cron-triggered curl to an internal monitoring endpoint close this gap cheaply.

Step 5: Test Restores Quarterly

An untested backup is a hypothesis, not a safety net. Schedule a quarterly full restore drill onto a scratch VM or spare partition, and time it — this is the only way you will know your actual RTO versus your assumed one.

Common Issues and Troubleshooting

• Backup window overruns into business hours — usually a bandwidth or disk I/O bottleneck. Check with iostat -x 5 during the job; if %util sits near 100% on the backup target disks, you are disk-bound and need to move to RAID 10 or add an NVMe cache tier.
• Deduplication ratio lower than expected — compressing data before it reaches the dedup engine (e.g., pre-gzipped database dumps) destroys dedup efficiency. Let the backup software handle compression after dedup, not before.
• Restore test fails silently — often caused by permission or ownership mismatches when restoring to a different host. Always test restores to a machine with matching UID/GID mappings or document the remap procedure.
• RAID rebuild takes days — large SATA drives (12 TB+) in RAID 5 can take 36-48+ hours to rebuild under load. This is the single strongest argument for RAID 6 on any backup array over 6 drives.
• Replication link keeps dropping — for offsite replication over the public internet, wrap the transfer in a tool that supports resume (rsync's --partial flag, or Borg's built-in resumable transfers) rather than restarting a multi-terabyte sync from zero after every disconnect.

Buyer's Checklist: What to Evaluate Before Choosing a Backup/DR Dedicated Server

• Does the provider support RAID 6 or RAID 10 out of the box, or will you need to configure software RAID yourself?
• What is the real, sustained (not burst) network throughput — ask for a speed test result, not just the advertised port speed.
• Is the data center geographically distinct from your primary production region (different power grid, different flood/earthquake zone)?
• Does the host offer IPMI/remote console access so you can recover the server itself if the OS becomes unbootable?
• Are hot-swap drive bays available, so a failed disk can be replaced without downtime?
• What is the hourly cost of remote-hands support if you need a technician to physically swap a drive at 3 a.m.?
• Does the provider allow you to bring your own backup software license, or lock you into a proprietary panel?
• What is the total cost including bandwidth overage if you need to perform a full restore download in a single month?

Frequently Asked Questions

How much storage do I actually need for a 3-2-1 backup strategy?

Plan for at least 2.5x your production data size per copy once you include incrementals and retention — for a 1 TB production database with 30-day retention, budget roughly 2.5-3 TB per repository, and you need at least two repositories (local + offsite) under the 3-2-1 model.

Is RAID considered a backup?

No. RAID protects against a single disk failure, not against ransomware, accidental deletion, fire, or a compromised admin account deleting everything. RAID is uptime protection for the backup server itself; it is not a substitute for offsite, versioned backup copies.

Should I use a dedicated server or cloud object storage (like S3) for backups?

Cloud object storage is excellent for the "one copy offsite" leg of the 3-2-1 rule because of its durability guarantees, but egress fees make it expensive for frequent full restores or DR testing. A common pattern is a dedicated server as your fast local repository plus a warm DR standby, with cloud object storage as a third, cheaper archival copy you rarely touch.

How do I calculate the right amount of bandwidth for offsite replication?

Take your nightly incremental size (not the full backup size) and divide by your replication window in seconds. A 200 GB nightly incremental replicated over an 8-hour window needs roughly 58 Mbps sustained — well within a 1 Gbps connection with plenty of headroom for other traffic.

Can I use a single dedicated server for both production and backups?

Technically yes, but it defeats the purpose of disaster recovery — if the server or its data center fails, both production and its backup are gone simultaneously. Always keep backup and DR targets on physically separate hardware, ideally in a separate facility or region.

How often should I test disaster recovery failover?

At minimum quarterly for a full restore test, and at least twice a year for a full DR failover drill (actually promoting the standby and routing traffic to it) if your RTO commitments are under 4 hours. Untested failover procedures routinely reveal missing DNS updates, stale credentials, or forgotten firewall rules.

Best Practices for Long-Term Backup and DR Operations

• Encrypt backups at rest and in transit — a stolen backup drive should not be a data breach.
• Keep at least one backup copy immutable or air-gapped so ransomware that reaches your network cannot encrypt your recovery point too.
• Document your restore procedure step by step and store it somewhere accessible even if your primary systems are down (not only on the wiki hosted on the server you are trying to recover).
• Monitor storage utilization trends monthly — backup data grows faster than most teams expect, and running out of repository space silently breaks new backup jobs.
• Rotate and verify backup integrity with checksums, not just "the job reported success."

Immutable and Air-Gapped Storage: Stopping Ransomware From Reaching Your Backups

Modern ransomware operators actively hunt for backup repositories before triggering encryption, specifically because a restorable backup removes their leverage. A growing number of incident reports describe attackers who spent days inside a network deleting or encrypting Veeam repositories, NAS snapshots, and cloud backup buckets before ever touching production data, precisely to force a ransom payment. Two architectural choices close this gap:

• Immutable storage — a repository configured so that, once written, backup data cannot be modified or deleted for a defined retention period, even by an account with administrative credentials. Object-lock-capable S3-compatible storage, ZFS with periodic snapshots locked against deletion, and Linux hardened repositories using an immutable file attribute (chattr +i) combined with a separate, tightly scoped backup account are all common implementations.
• Air-gapped storage — a copy that is physically or logically disconnected from the network the vast majority of the time, such as a rotation of removable drives taken offsite, or a repository server that only opens a network path to receive replication during a narrow nightly window and is otherwise firewalled off entirely.

A practical middle ground many teams adopt on a Linux repository server is a hardened, dedicated backup account with no interactive shell, write-once permissions enforced at the filesystem level, and a separate administrative account (with MFA) required for any retention policy change — so that even if a production system's credentials are compromised, the attacker cannot reach or alter the backup copies from that foothold.

Choosing Backup Software: Feature and Cost Comparison

The backup software layer matters as much as the hardware underneath it. Deduplication ratio, encryption support, and restore granularity vary significantly between the major options teams run on a dedicated repository server:

Teams standardizing on VMware or Hyper-V infrastructure typically get the fastest time-to-value from Veeam because of its application-aware backup and one-click instant VM recovery, while Linux-native shops running bare-metal or container workloads often prefer BorgBackup or restic for the lower licensing cost and equally strong deduplication, at the expense of needing to build their own alerting and reporting around the CLI tools.

Calculating True Cost of Ownership: Dedicated Server vs Cloud Backup Storage

Sticker price comparisons between a dedicated backup server and cloud object storage miss the two line items that dominate real bills at scale: egress fees and API request costs during a restore. A worked example clarifies why:

This is not an argument against cloud storage broadly — it remains an excellent choice for the offsite leg of a 3-2-1 strategy specifically because of its durability guarantees. The point is that a dedicated server as your primary, frequently-tested repository avoids the scenario where the cost of recovering from a disaster is itself a financial shock on top of the outage.

Advanced Topic: Synthetic Full Backups and Storage Efficiency

Running a true full backup every night is wasteful — most of the data has not changed since yesterday. A synthetic full backup solves this by combining a previous full backup with subsequent incrementals, entirely on the backup server, to produce a new "full" restore point without re-reading the entire production dataset over the network. Veeam, Bacula, and Borg (via its deduplicated chunk store) all support this pattern in different ways. The storage and bandwidth savings are substantial: a nightly synthetic full on a 2 TB database with a 3% daily change rate touches roughly 60 GB of new data server-side, compared to re-transferring the full 2 TB from production every night — a reduction of over 95% in nightly transfer volume, which is often the difference between a backup job that comfortably fits an overnight window and one that does not.

Best Practices for Long-Term Backup and DR Operations

• Encrypt backups at rest and in transit — a stolen backup drive should not be a data breach.
• Keep at least one backup copy immutable or air-gapped so ransomware that reaches your network cannot encrypt your recovery point too.
• Document your restore procedure step by step and store it somewhere accessible even if your primary systems are down (not only on the wiki hosted on the server you are trying to recover).
• Monitor storage utilization trends monthly — backup data grows faster than most teams expect, and running out of repository space silently breaks new backup jobs.
• Rotate and verify backup integrity with checksums, not just "the job reported success."
• Use synthetic full backups where your software supports them to cut nightly bandwidth and storage churn dramatically.
• Separate the administrative account that can change retention policy from the service account that performs day-to-day backup writes.

Frequently Asked Questions (Continued)

What is the difference between immutable and air-gapped backups?

Immutable backups remain network-connected but are enforced (at the storage or filesystem layer) to reject modification or deletion for a defined period, even against an administrator account. Air-gapped backups go further by physically or logically disconnecting the copy from the network most of the time. Many teams combine both: an immutable primary repository plus a periodically air-gapped offsite rotation.

How do synthetic full backups reduce cost compared to traditional full backups?

A synthetic full is assembled from an existing full backup plus incrementals directly on the repository server, avoiding a full re-read and re-transfer of production data every cycle. For a 2 TB database with a 3% daily change rate, this can cut nightly transfer volume by well over 90% compared to running a true full backup on the same schedule.

Should I choose Veeam, an open-source tool, or a custom script-based approach?

Veeam and similar commercial platforms make sense when you are backing up VMware/Hyper-V environments and want vendor support plus a polished UI for the whole team; open-source tools like BorgBackup or restic fit Linux-heavy, bare-metal, or container environments where a smaller team is comfortable operating CLI-driven tooling in exchange for zero licensing cost.

How do I estimate the true cost of a cloud-only backup strategy versus a dedicated server?

Model the cost of an actual full restore, not just monthly storage — cloud egress fees during a real disaster recovery event can add hundreds to low thousands of dollars on top of your regular storage bill, while a dedicated server's bandwidth is typically included, making its total cost of ownership far more predictable when you actually need to use it.

A dedicated server built specifically for backup and disaster recovery removes the guesswork of shared-tenant storage limits and gives you full control over retention, RAID configuration, and network throughput. WebsNP's Linux dedicated server plans support large hot-swap storage arrays and 10 Gbps uplinks suited to backup repositories and warm DR standbys, and our dedicated IP options make offsite replication and remote restore access straightforward to lock down. If you are architecting a 3-2-1 strategy across regions or need help sizing a repository for your retention policy, contact our team for a configuration built around your actual RPO and RTO numbers.