IT Support, Networking and Infrastructure · Virtualisation and server infrastructure
Backup, storage and disaster recovery
A backup nobody has tried to restore is a hope rather than a plan, and most organisations discover which one they own on the worst day of the year. This part of infrastructure covers where data lives, how copies are taken and kept apart from the original, and how long the business can afford to wait for systems to return. It is dull right up to the moment it is the only thing that matters.
Why this topic exists: Storage tiers, backup schedules, restore tests and continuity plans are the part of infrastructure nobody funds until the day it is needed (SFIA Storage management and Continuity management; Network+ disaster recovery under Network operations; A+ Core 2 operational procedures).
The work begins with a question that sounds trivial and rarely is: where does the organisation's data actually sit? Part of it lives on laptop disks, part on a file server or a NAS in a cupboard, part on the storage behind the hypervisors, and a growing share inside cloud services the IT team never chose. SFIA gives storage management its own skill, covering the setting up and tuning of storage whether it runs in-house or with a provider, and treats continuity management as a separate one: writing a continuity framework and proving it by exercise. The two meet in the backup, a copy kept somewhere the failure of the original cannot reach.
Two numbers every plan needs
A recovery plan rests on two figures agreed with the business. The recovery point objective says how much recent work may be lost, expressed as time since the last good copy. The recovery time objective says how long a service may stay down before the damage becomes unacceptable. Network+ names both in its Network operations domain, next to mean time to repair, mean time between failures and the choice of standby site. Those same promises often hide inside an uptime SLA, which is why an administrator should read the contract before designing the schedule.
| Standby option | What is ready when disaster strikes | The trade-off |
|---|---|---|
| Cold site | Space, power and connectivity; hardware and data have to be brought in | Cheap to hold, slow to use |
| Warm site | Equipment in place, data restored from the most recent copies | Some data loss and some delay, at moderate cost |
| Hot site | Systems running with near-current data, able to take the load quickly | Shortest outage, highest standing cost |
| Active-active | Both locations carry live traffic all the time | No switchover step, but every change must work in two places |
Habits that hold up on the bad day
- Keep more than one copy, on more than one kind of media, with at least one away from the building and one that cannot be altered once written.
- Send off-site copies to object storage with versioning or retention locks, so an overwritten or deleted file can still be recovered.
- Protect every copy that leaves the site with encryption, and keep the keys somewhere other than beside the backup.
- Give the backup system its own credentials, separate from everyday admin accounts. Attackers deploying ransomware look for the backup console before they encrypt anything else.
- Run restores on a schedule and write down how long each one took. That measured figure, not the plan, is your real recovery time.
RAID keeps you running, not safe
Mirrored or striped disks keep a server online when a drive dies. They copy an accidental deletion, a corrupted file or an encrypted volume to every disk just as faithfully, so they protect availability and never history.
The classic beginner's error is to confirm that the backup job reports success and stop there. A job can succeed for months while copying the wrong folder, skipping locked files or writing to a disk that is quietly filling up. A+ Core 2 places workstation backup and recovery under operational procedures, which is where a support technician first meets the subject; A+ and Network+ supply the vocabulary, and Cloud+ takes the same questions onto rented infrastructure. The parent topic is virtualisation and servers; the cloud side continues under cloud storage and databases, and the hour after an attack belongs to incident response.
Concepts to know
Glossary entries with the reason each one matters here.
- Uptime & SLA
Recovery objectives are what an SLA silently promises.
- Ransomware
The incident that turns a backup policy into a business question.
- Object Storage
Where off-site backups increasingly live.
- Encryption
Backups leave the building; they travel encrypted or not at all.
Certifications that test it
Vendor exams and free certificates; facts, cost and the preparation path are on each page, and the certifications hub has them all.
Frequently asked
- How does a backup differ from disaster recovery?
- A backup is a copy of data. Disaster recovery is the whole plan for bringing services back after a serious failure: the copies, the hardware or cloud capacity to restore them onto, the order in which systems return, and the people who decide. You can own excellent backups and still have no recovery plan.
- How often should restores be tested?
- There is no universal interval. Test after every significant change to the systems being protected, and on a regular schedule the business has agreed to, restoring a sample of files often and a whole system less often. What matters is that the result and the time taken are recorded.
- Doesn't my cloud provider back up my data already?
- Providers keep their service running, which is not the same promise. Many do not undertake to bring back what a user deleted or a script overwrote beyond a limited retention window. Read the service terms, and treat data in software-as-a-service tools as something you may still need to copy yourself.
Courses in the directory
31 courses are filed here; the top 6 by our ranking, details and the provider link on each course page.
Last reviewed 26 September 2026 · Getting Digital