Backup Hardware: Choosing Targets and Testing Restores
Backups get built once and then trusted for years without anyone checking whether they still work. This covers what the hardware side of a backup actually needs to do, and the checks that turn an assumption into a plan.
The rule, and what it means for hardware
Three copies of the data, on two different media types, with one copy off-site. That is the shape almost every workable backup takes.
What it means in hardware terms.
The production copy is your array. RAID is not one of the three copies — it protects against a drive failing, not against deletion, corruption, ransomware or the array itself failing. Our RAID guide covers that distinction.
The second copy is usually a separate array, NAS or backup appliance on site. Separate hardware, separate power, separate controller.
The third copy is off-site — tape taken away, a second site, or cloud. This is the one that survives fire, flood and theft.
Choosing backup target hardware
Four things.
Capacity for retention, not just for one copy. How many versions you keep, for how long, decides the size. This is almost always larger than people first estimate. Our capacity planning guide covers sizing.
Write speed against the backup window. A backup that no longer fits its window has quietly become a backup that does not complete.
Drive class. CMR, and NAS or enterprise class. SMR drives look attractive for backup because they are cheap per terabyte, and they are acceptable only for single-drive sequential targets — never in an array. Our SMR guide covers why.
Separation from production. A backup on the same array, same controller or same power feed as the production data is not a second copy in any useful sense.
Tape, disk or both
Disk is fast to write and fast to restore from, which makes it the right first target. It stays powered, connected and online, which is also its weakness — anything that can reach your production data can frequently reach an online backup.
Tape is cheap per terabyte, lasts for years on a shelf, and is offline once removed from the drive. That physical disconnection is genuinely valuable, because a tape in a cupboard cannot be encrypted remotely. Our tape guide covers what a tape setup involves.
The common arrangement is both: disk for recent backups and fast restores, tape for longer retention and the off-site copy.
The thing nobody tests
Restores.
A backup job that reports success has demonstrated that it ran. It has not demonstrated that the data is complete, readable, or restorable to a working system. Those are different claims, and only a restore test proves them.
Three levels of test, in increasing usefulness.
Restore a file. Proves the media is readable and the catalogue works. Do this monthly.
Restore a full system to spare hardware. Proves the backup is complete and the process works. Do this at least annually, and after any significant change.
Restore under time pressure, with the usual person unavailable. Proves the documentation is adequate and someone else can do it. This is the test that finds the real gaps.
Hardware for restores
The part of backup planning that gets forgotten entirely.
If your restore plan is "restore to the same server", and the reason you are restoring is that the server failed, the plan has a hole in it.
Two practical answers. Hold a cold spare machine for platforms that matter, configured and tested, ready to receive a restore. Our spares guide covers this. Or confirm the restore works to different hardware, which is not always straightforward on bare-metal restores. Our DR guide covers planning for it.
Six questions worth answering now
Where are the three copies, physically? What is the off-site copy and when was it last taken off site? How long would a full restore take? When did anyone last restore a full system? Who can do it besides the usual person? What hardware would receive the restore?
Any question you cannot answer is a gap, and gaps in backup are only ever discovered at the worst moment.
Frequently asked questions
Is RAID a backup?
No. RAID protects against a drive failing. It does not protect against deletion, corruption, ransomware, or the array itself failing. It is not one of your three copies.
Can I use SMR drives for backup?
Only for single-drive sequential targets, never in an array. Write speed collapses part-way through a sustained transfer once the buffer fills, and a rebuild onto an SMR drive can fail.
Why does tape still exist?
Because it is cheap per terabyte, lasts years on a shelf, and is offline once removed from the drive. That physical disconnection is genuinely valuable — a tape in a cupboard cannot be encrypted remotely.
How often should I test restores?
Restore a file monthly to prove the media and catalogue work. Restore a full system to spare hardware at least annually and after significant changes. A job reporting success proves only that it ran.
What hardware do I restore to if the server failed?
That is the hole in most backup plans. Either hold a cold spare machine for platforms that matter, configured and tested, or confirm the restore works to different hardware, which is not always straightforward on bare-metal restores.
Can the backup live on the same server?
Not usefully. A backup sharing the array, controller or power feed with production data is not a second copy in any meaningful sense. Separation is the point.
Tell us your data size, retention period and backup window, and we will size a target that will still complete in that window next year.
