Backup coverage works by identifying everything needed to recover a particular activity, not merely everything inside a convenient folder. The question is simple: when the original environment is unavailable, do the preserved files, data, settings and access arrangements add up to usable work?
A complete-looking archive can still omit one essential dependency. A spreadsheet may open without its external source. A teaching folder may contain the questions but not the matching answers. A website export may preserve articles while leaving the actual images elsewhere. The missing item is sometimes tiny, yet its absence changes the whole result.
This guide develops the coverage pillar of How Digital Backups Fail. It focuses on what must be preserved, what can be rebuilt and how to test the boundary. Protection against shared failure belongs in How Backup Isolation Works; proving the recovered activity belongs in How Restore Testing Works.
The cases below are invented for teaching. They do not describe eduKate’s actual storage systems, and they are not permission to export personal records or alter a live application. Begin any practical exercise with authorised, non-sensitive sample material.
Define Recovery Before Counting Files
Consider two targets: “recover the final report” and “resume editing the project.” The first may require one readable document. The second may require source data, editable figures, references, comments and the software needed to continue. Neither target is inherently wrong. The mistake is choosing one backup scope while promising the other recovery outcome.
Write the target as an observable activity. For a student, that might be opening the editable report, updating one chart and exporting the submission. For a teacher, it might be retrieving the correct lesson version and checking its answer key. For a publisher, it might be displaying a restored article with the assets and behaviour needed by readers.
Then ask what the activity consumes. Work backwards from the final action rather than forwards from the folders currently visible. This is the same useful reasoning move as identifying a prerequisite in Mathematics: the target determines which earlier conditions are necessary. A long inventory is valuable only when its entries have a relationship to the recovery target.
AWS’s reliability guidance explicitly includes applications and configuration alongside data when discussing recovery. Use that as a reminder that a functioning environment may require more than the files people normally call their work. [1]
The Five Coverage Questions
A useful first pass has five questions: what is the required output, where is its authoritative source, which dependencies make it usable, which point in time must be recoverable, and what evidence would reveal an omission? These questions keep the map grounded in actual work.
What is the output?
Name the artefact or service precisely enough that two people can recognise the same result. “School files” is a category. “The editable science project and its source measurements for the current submission” is a recoverable unit. The right level of detail depends on the task, but the boundary should not depend on one person remembering what they meant.
Which source is authoritative?
A downloaded copy may be older than the online version. An emailed attachment may predate the teacher’s corrections. An exported file may represent only selected records. Identify which location defines the current work and which locations are convenient derivatives. Otherwise, the backup can preserve an outdated copy with complete technical accuracy.
What makes the output usable?
Look for linked files, metadata, permissions, application settings and version relationships. A question paper and an answer key form a pair. A chart and its data source form another. The inventory should preserve the relationship, not simply list the two filenames as unrelated objects.
Which history matters?
Current state and recoverable history are different dimensions of coverage. A recent copy may be sufficient after device loss. An unnoticed mistaken edit may require an earlier version. Ask how far back a problem might need to be traced, and do not let a schedule of new copies silently eliminate the history needed for that investigation.
What would expose a missing part?
For every important dependency, name a check. Recalculate a chart, follow a link, retrieve a sample record, open a selected attachment or compare the question version with the answer version. “The archive opens” is too broad when the required activity has several distinct parts.
Map the Different Kinds of Material
Original content
Original content is the work that would be difficult or impossible to reproduce: research measurements, an editable manuscript, original photographs, a student’s working or a teacher’s custom explanation. Give such material explicit attention. Its value is not necessarily reflected by file size, age or how often it is opened.
A large downloaded reference file may be easy to obtain again. A small spreadsheet containing unique observations may not be. Coverage should follow the consequence of loss, not the amount of storage occupied. This also helps a family or small team keep the first recovery plan manageable.
Application data
Some important information lives inside an application rather than in ordinary documents. Examples include records, comments, relationships, version histories and attachments. Ask what the supported export or backup actually contains. A visible screen, a printable report and a recoverable application state can be three different things.
Configuration and software requirements
A recovered data file may require an appropriate application, version, extension or setting. Record the requirement and the legitimate way to obtain it. Do not assume that the old installation, account or licence will automatically be available on the recovery device. Equally, do not copy software in a way that ignores its licence or the organisation’s security rules.
Metadata and relationships
Filenames are not the only information that matters. Ordering, timestamps, authorship, labels, permissions and links between records can determine how an application interprets the content. A pile of recovered attachments may be much less useful when their associated records are absent. Ask whether the restore can reconstruct meaning, not just bytes.
Access dependencies
Credentials and encryption keys are not ordinary project attachments. The coverage map should identify the protected access arrangements needed for recovery without placing the secrets themselves in a shared document. Record the authorised owner, the approved recovery procedure and any dependency on a device, account or specialist who might be unavailable.
Preserve or Rebuild? Make the Choice Explicit
Not every dependency has to be stored as a complete duplicate. Some items can be reproduced from reliable sources. The key word is reproduced, not merely imagined. A rebuild route should identify the source, required access, compatible version and time needed to make the result usable.
Suppose a report contains a chart generated from preserved data and a known procedure. Recreating the chart may be acceptable. But if the procedure depended on an unrecorded manual adjustment, the chart is no longer reliably reproducible. The coverage decision changes when the hidden step becomes visible.
Use three clear dispositions: preserve directly, rebuild from a documented source, or exclude deliberately. Add a reason to the third category. Temporary files may be irrelevant to the recovery target. A completed output may be sufficient for an archive but insufficient for continued editing. A deliberate exclusion is a decision; an unnoticed exclusion is a gap.
The rebuild time belongs in the recovery estimate. “We can download that again” is not a complete plan when the account is locked, the network is unavailable or the required version has disappeared. Test the route under the assumptions that make it important. Where uncertainty remains, state it rather than silently treating rebuildability as proven.
Why Database and Application Consistency Matters
Ordinary documents encourage a simple mental model: copy a file, open the copy. Applications may need a richer model because several files or records represent one logical state. A record created at one moment may refer to an attachment or transaction stored elsewhere. The recovery method must preserve a usable relationship among them.
PostgreSQL’s filesystem-backup documentation explains why a naive copy of a running database is not automatically usable and describes consistency requirements for supported alternatives. The important lesson here is not a universal command. It is that the application’s own recovery model determines which components must be captured together. [2]
For a non-specialist, the safe action is to ask the system owner which supported method is in use and what it guarantees. Does it include the necessary logs and settings? Is the result application-consistent or dependent on a recovery procedure? Which version of the software is required? Do not improvise filesystem copies of a live database to answer these questions.
A small educational analogy helps. Imagine copying the questions from one edition of a worksheet and the answers from another. Every page may be present, yet the set is inconsistent. The analogy is not a database specification; it simply shows why completeness of parts does not establish compatibility of the whole.
Coverage Across Time: Recent Enough and Old Enough
A recovery plan needs two temporal questions. How recent must the recovered state be? How far back might a clean state need to exist? The first protects recent work. The second protects against damage discovered late. Improving one does not automatically solve the other.
Imagine that a class project changes each afternoon. The family wants a recovery point no more than one study session old. Separately, a mistaken change might remain unnoticed until the teacher reviews the project a week later. A plan that keeps only the latest copy may satisfy neither need when the job fails or the newest state already contains the mistake.
The NCSC’s cloud-backup principles discuss retaining earlier recoverable versions and protecting them from being displaced by a rapid series of corrupted copies. This is why a count such as “the last five backups” is not necessarily the same promise as “the last five days.” [3]
Choose retention for the work and its obligations, not from an arbitrary slogan. Some material should not be kept indefinitely. Where legal, institutional or contractual retention rules apply, use the organisation’s policy and qualified advice. A learning exercise should never become a reason to export or retain personal records without authority.
Worked Case 1: A Student’s Investigation Project
Alicia is preparing an investigation about water use. Her deliverable is a report, but the work depends on a measurement spreadsheet, a chart, two original photographs, the assignment brief and a record of source references. A PDF of the report is useful for reading; it does not preserve every part needed to continue the investigation.
She writes the recovery target first: “On another authorised computer, I can inspect the measurements, change one assumption, rebuild the chart and export the report with its images.” This immediately distinguishes editable sources from final outputs. It also exposes the application requirement: a compatible spreadsheet editor and a document editor must be available.
Her inventory identifies six groups of material. The measurements and original photographs are preserved directly. The editable report and source references are preserved directly. The chart can be reproduced only after she records how it is generated. The assignment brief is preserved through an authorised route so its requirements remain clear.
During the practice restore, the chart initially points to its original location. She discovers this by changing a sample value in the recovered spreadsheet, not merely opening the report. After correcting the relationship in the practice copy, she can reproduce the expected chart. The test turns an abstract inventory into evidence about a working dependency.
The lesson is precise: identify the operation that proves each dependency. A file count would not have exposed the broken relationship. Repeating the activity from the restored material did. No original file needed to be deleted to learn this.
Worked Case 2: A Publisher’s Website
A small publisher downloads a content export and calls the website backed up. The claim needs a boundary. WordPress’s documentation distinguishes exported content and media references from actual media files and other site components. Its separate media-library guide explains how uploaded files are exported through the appropriate route for the site. [4] [5]
For this fictional publisher, the recovery target is to restore ten essential reference articles so readers can use them. The inventory therefore checks article content, actual images, relevant structured fields, navigation relationships and the software or configuration needed to display them. A successful import message is useful evidence, but it does not answer every one of those questions.
The publisher also distinguishes reading from operating. Displaying an article is one activity. Accepting a genuine enquiry, sending a notification or processing a payment is another. A recovery test should not activate those live operations accidentally. Coverage can identify the dependency while leaving its live execution to a separately authorised test plan.
The useful conclusion is not that one export method is bad. It is that every method should be matched to the claim being made about it. “We preserved these written articles” may be true. “We can rebuild the complete service without the original environment” requires broader evidence.
Worked Case 3: A Teaching Resource Collection
Tricia has 50 resource files and confirms that 49 were copied. A coverage dashboard displays 98%. The missing file is the index connecting each question set to its correct answer version. The percentage looks excellent, but the missing relationship affects many lessons.
Now change the case: suppose the missing file is an easily recreated thumbnail and every lesson still works. The same 98% would imply a much smaller problem. The arithmetic is unchanged; the consequence is different. File-count coverage is not a probability that recovery will succeed.
Tricia separates three measures: items captured, essential dependencies accounted for, and target activities successfully demonstrated. These measures should remain distinct. A high capture count cannot cancel an untested lesson, and one successful lesson does not prove the whole collection.
She prioritises the shared index, checks several version pairs and records the scope of the test. Further testing can then cover remaining resource types. This is a more useful progression than repeatedly polishing the percentage without investigating what the missing material does.
Build a Coverage Register That Somebody Can Maintain
A register need not become a large database. For a student, it may be a short document. For a team, it may be a controlled inventory. The useful fields are the target activity, important object, authoritative location, preservation method, dependencies, required history, responsible owner and a check that would prove usability.
- Target: the work that must resume, with a clear acceptance condition.
- Scope: the objects included, their dependencies and explicit exclusions.
- Method: preserve directly, rebuild from a documented source, or exclude by decision.
- Evidence: last usable recovery point, test result, remaining uncertainty and review trigger.
Keep secrets out of the register. “Recovery access is held through the approved administrator procedure” is different from recording a password in the same sheet. The register should help authorised people find the correct process without becoming an uncontrolled access catalogue.
Assign ownership to the work, not merely to the backup tool. Someone must notice when a new application becomes important, a folder moves or a linked asset is added. A tool can only protect what its configuration and access permit; it cannot infer every change in the organisation’s recovery priorities.
Coverage Needs Change Triggers
Review coverage when the work changes. Useful triggers include a new device, application, account, storage location, project type or external integration. A new export format may alter what is preserved. A staff change may alter who can interpret the inventory. The date of the last successful job does not prove these changes were considered.
For a student, the trigger may be moving from simple essays to projects with linked datasets and media. For a teacher, it may be introducing a new assessment platform. For a publisher, it may be adding a form or changing the content structure. The coverage review should follow the new dependency rather than repeat an unchanged checklist mechanically.
Also review unexpected recovery results. A missing image, unreadable format or unmatched answer key is evidence that the map was incomplete or the method did not implement it. Close the gap in the inventory and the process, then test again. Repairing one recovered file without updating the method leaves the same failure available next time.
Teach the Method Through Small, Observable Steps
Start with one deliberately simple activity: a sample document containing an image. Ask the learner which objects must survive, then restore into a separate folder. Once that relationship is understood, introduce one additional dependency, such as a chart generated from a second file. Increasing complexity one condition at a time makes the missing link easier to see.
Next, separate outputs from sources. Give the learner a final PDF and ask whether it is sufficient to continue editing. The answer depends on the target. This avoids teaching a rigid rule that every output is inadequate or every editable file is necessary. The learner practises matching scope to purpose.
Finally, ask the learner to explain a new case without help. What would a restored audio project need? What about a spreadsheet that imports external data? The goal is transfer: seeing the dependency pattern in unfamiliar work rather than memorising a list of folders.
Independent application
Choose an authorised practice project and write three statements: “I must preserve…”, “I can rebuild…”, and “I am deliberately excluding…”. For every statement, give a reason tied to the target activity. Then identify one observation that would prove the plan wrong. This last step is important: a coverage plan should be capable of failing a test.
Progress check
Early progress means finding all visible files. Stronger progress means identifying hidden relationships. A mature explanation includes historical versions, access dependencies and the limits of the evidence. The learner should be able to say, “This activity was demonstrated; these other activities remain untested,” without feeling that honest uncertainty is a weakness.
Frequently Asked Questions
Does selecting every folder establish complete coverage?
It establishes a broad selection, not necessarily a recoverable activity. Some information may live inside an application, depend on an external account or require a consistent capture method. Start with the recovery target and test the required operation. A folder list is one input to that test, not the conclusion.
Must every application be copied into the backup?
Not necessarily. An application may be legitimately reinstallable or provided through a managed recovery process. Record how it will be obtained, which version is compatible and what access is required. Include the time needed to rebuild the environment rather than treating installation as an invisible step.
How should passwords and encryption keys appear in the map?
As protected access dependencies, not as exposed values. The map can identify the authorised owner and recovery procedure. The actual secret belongs in an approved protected system. A recovery plan should reduce dependence on one failed device without increasing uncontrolled access to sensitive information.
Why preserve an old version when a newer one exists?
A mistake can be discovered after several newer copies have been created. The newer versions may all contain the same problem. A suitable history lets the owner select a point before the unwanted change. How much history is appropriate depends on discovery delay, recovery needs and applicable retention requirements.
Is a content export useless as a backup?
No. It can be valuable for the content it actually preserves. The mistake is calling it a complete service backup without checking the omitted components. Describe the scope honestly, preserve other necessary assets through appropriate methods, and test the specific result you intend to recover.
Should coverage be expressed as a percentage?
A percentage can answer a well-defined inventory question, such as how many listed objects were captured. It cannot by itself express the consequence of each omission or the probability of usable recovery. Keep inventory completion, critical-dependency coverage and demonstrated recovery outcomes separate.
When should a specialist review the coverage plan?
Seek authorised technical review when the plan involves live databases, sensitive records, specialised applications, important integrations or recovery after compromise. A classroom file exercise is useful for understanding dependencies, but it does not qualify someone to redesign a production backup method.
What is the smallest useful coverage audit?
Take one activity, identify its authoritative material and required dependencies, and attempt the acceptance check from a safely restored copy. Record what was missing or assumed. This produces a concrete improvement without requiring a complete inventory of every digital item before any learning can begin.
Helpful Reading Across eduKate
Use dependency criticality to distinguish essential inputs from helpful ones, and summary coverage to compare another kind of careful selection. A short representation and a backup both need an explicit purpose, but they preserve different things and require different tests.
For broader navigation, use the eduKateSingapore Project Atlas. For family planning, the eduKate Punggol Family Decision System offers a place to continue thinking about who decides and what evidence matters. Neither link replaces the technical documentation for a particular backup service.
Sources and Further Reading
- [1] AWS Well-Architected Reliability Pillar: Back up data.
- [2] PostgreSQL documentation: File System Level Backup.
- [3] NCSC: Principles for ransomware-resistant cloud backups.
- [4] WordPress.com Support: Export your site’s content.
- [5] WordPress.com Support: Export your media library.
A Better Coverage Claim
Replace “everything is backed up” with a statement somebody can test: “These activities are covered by these preserved objects and rebuild routes; these histories are retained; these checks have passed; these gaps remain.” The claim becomes more useful because its boundary is visible.
Return to How Digital Backups Fail, then continue with How Backup Isolation Works and How Restore Testing Works.