Almost every organization has backups. A smaller number have restores. The distinction matters because backup software reports on the job it ran, not on whether the data it wrote can be turned back into a working system, and those are different questions with different answers.
This page covers what backup and data protection involve as an operational discipline: deciding what to protect, where copies live, how long they are kept, how they are secured, and how the whole arrangement gets tested before it is needed.
Start from what a restore has to produce
The useful design question is not "what should we back up" but "what would we need in order to be working again". Those produce different inventories. A file-level backup of an application server restores files; it does not restore an operating system, a configuration, a certificate, a license key, a DNS record or the person who knew the install order.
Working backwards from a restored, functioning service tends to surface the things a backup scope quietly omits: build configuration, secrets, infrastructure definitions, and the documentation describing how the parts fit together.
Scope, and the systems nobody listed
Backup scope drifts. Systems are added without being added to the job; virtual machines are cloned and the clone inherits nothing; a team stands up a database in a cloud account that the backup platform cannot see.
The control is reconciliation rather than inspection. Compare the list of things being backed up against an independent inventory of things that exist, on a schedule, and treat every difference as a question. The systems that fail this comparison are almost never the important ones anybody would have thought to check.
Frequency follows the recovery point you agreed
How often a backup runs determines how much work is lost when it is used. If the business agreed to a four-hour recovery point objective and the job runs nightly, the agreement and the configuration disagree, and the configuration is what will be true during the incident.
This is the same arithmetic set out in Disaster Recovery: RTO, RPO and Recovery Planning, and it is worth doing per system rather than per estate. Different data has different tolerance, and paying for a fifteen-minute recovery point on a file share that changes weekly is how budget gets spent where it does nothing.
Where the copies live
The long-standing rule of thumb asks for multiple copies, on more than one kind of media, with at least one held somewhere else. Its value is not the specific numbers but the failure modes it forces you to consider separately: the copy that shares a storage array with production, the copy that shares a building, and the copy that shares an administrative credential.
That last one is the modern version of the problem. A backup replicated to a second region is protected against the first region failing and not at all against an account being compromised, because the same credentials reach both.
Immutability, and why it became the main event
Backups are now a target. An attacker who encrypts production and deletes backups has removed the option that makes the rest survivable, and doing so requires nothing more sophisticated than the credentials your backup system already holds.
Immutable storage answers this by making a copy undeletable for a defined period, including by an administrator. It is the single change that most improves the odds during a ransomware incident, and it has to be arranged before the incident because its whole value is that it cannot be arranged during one. The threat side of this, including how an attack unfolds and what response looks like, is covered in Backup, Recovery and Cyber Resilience.
The control is a formal requirement, not an opinion
Federal control catalogues state this directly. NIST SP 800-53 Revision 5 control CP-9, SYSTEM BACKUP, requires organizations to conduct backups of user-level information, system-level information and system documentation including security- and privacy-related documentation, at a defined frequency consistent with recovery time and recovery point objectives, and to protect the confidentiality, integrity and availability of backup information. See NIST SP 800-53 Revision 5.
Two things in that wording are regularly missed in practice: system documentation is explicitly in scope, and the frequency is supposed to be derived from the objectives rather than chosen for operational convenience.
Retention is a policy question wearing a technical costume
How long to keep a copy is decided by regulation, contractual obligation, the realistic window for noticing a problem, and cost. Only the last of those is a technical input.
The window for noticing matters more than people expect. Data corruption discovered eleven months after it began is unrecoverable if the retention is ninety days, and the corruption is silent by definition or it would have been found sooner. Long-interval retention points are cheap insurance against slow failures.
Encryption, and the key you will need later
Backups contain everything production contains, in a form that is easier to carry away. They should be encrypted in transit and at rest, which is uncontroversial and usually done.
What is less often done is planning for the key. A key held only in the system being recovered is not available during the recovery, which is a category of failure discovered at the worst possible moment. Key custody, escrow and the documented procedure for using a key in an emergency belong in the design, not in someone's head.
Testing is what turns a backup into a recovery capability
A restore test is the only evidence that any of this works. Everything upstream of a restore is a plausible story about what would happen.
Tests should vary: a single file, a full system, a database to a point in time, and at least occasionally a restore into somewhere other than where the data came from. That last variation is the one that finds the assumptions, because restoring in place quietly reuses the network, the names, the credentials and the licensing that a real disaster would have taken away.
Record what the test measured
The output of a restore test is a time and a state. How long it took, what was restored, what was missing, what had to be done by hand, and what was learned. Without the record, the test proves something once and proves nothing later.
The records accumulate into the most valuable artifact in this whole discipline: a realistic, evidenced statement of how long recovery actually takes, which is the number executives believe they already have and usually do not.
Databases need their own treatment
Copying database files while the database is running produces a file that may or may not restore, and the failure is not apparent at backup time. Databases need a mechanism that understands them: a consistent snapshot, a native dump, or log shipping that supports point-in-time recovery.
Point-in-time recovery is worth the extra work whenever the plausible failure is logical rather than physical. A dropped table, a bad migration or a deletion that replicated everywhere is not helped by a copy of the same mistake; it is helped by the ability to return to a moment just before it.
Cloud does not remove the responsibility
A managed database service handles the machinery of backup and leaves the decisions with you: what retention is set, whether copies exist outside the account, whether deletion is prevented, and what happens if the account itself becomes the problem. Provider durability guarantees cover the storage, not your ability to undo what you did to it.
The boundary is set out in Cloud Security and Shared Responsibility, and backup is one of the clearest examples of a control that sits on the customer's side of it whatever the console suggests.
Monitoring the thing that is supposed to be quiet
Backup failures are quiet by nature. A job that stops running produces no output and therefore no attention, which is why the failure is typically discovered by the restore that needed it.
The fix is to monitor for success rather than for failure: alert on the absence of a completed job within the expected interval, on a backup whose size departs from its trend, and on the age of the newest recoverable copy per system. That last metric is the one worth putting on a dashboard, because it is the number that matters and it is not the number backup software reports.
What running this as a service looks like
LABUSA's approach to infrastructure work is boundary-first: agree what is in scope, what is not, and who holds each responsibility before the operational work starts. For backup that means an explicit scope, agreed recovery objectives per system, a documented restore procedure, a testing schedule that is actually run, and reporting on recovery readiness rather than on job counts.
It also means treating the scope as something that changes. New systems join the estate constantly, and a backup service whose inventory is a year old is protecting last year's environment. The infrastructure service backup sits inside describes how this fits with monitoring, server management and recovery planning.
Where backup stops
Backup restores data. It does not restore a service, which also needs infrastructure, network, configuration and a sequence. Getting from restored data to a working business is continuity work, covered in Disaster Recovery and Business Continuity.
The reason to keep the two distinct is that organizations with excellent backups and no continuity plan still take days to recover, and they are usually surprised by it.
The federal guidance draws the same line. NIST puts the recovery point at the centre of the backup decision, describing it as the point in time, prior to a disruption or system outage, to which mission and business process data can be recovered after an outage, and treating backup as one contingency strategy among several rather than the whole plan. See NIST SP 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems. Read that way, a backup schedule is an answer to a question the continuity plan asks, and reversing the order is how estates end up with a schedule nobody can justify.