About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
A backup job succeeds when the backup system finishes the work it was asked to do and records that finish. A restore succeeds when the data from a named copy is read back and a named function can use it. Those events happen at different times, on different machines, and they answer different questions. A green job is evidence about the night the copy was made. It is not evidence about the morning you need the data.
Treat the checks as a stack. Each layer is worth doing. Each layer supports only its own sentence.
| Check | Sentence it can support |
|---|---|
| Job completed without an error status | The backup system reported that this run finished |
| Bytes or object count match the job's own report | The run's accounting agrees with itself |
| The copy is present in the store you intended | Delivery to that store happened |
| A cryptographic hash matches a trusted reference, or a signature verifies with a trusted key | The bytes match the trusted reference or the verified signature |
| A file, database, or message from that copy opens in the application that owns it | That content can be used |
| The open was timed and the copy's age was written down | You have a measurement toward a recovery time and a recovery point |
Stopping at the first row and reporting the last row is the failure this article is about. The examples are hypothetical. No backup job was run for this article.
Why it matters
The controls discussed here apply where your organisation has selected or is required to meet them. They are not a blanket legal requirement for every business.
People trust the status they see every day. The status they see every day is the job. The status they need on the worst day is the open. NIST SP 800-53 control CP-9 requires backups of user-level information, system-level information, and documentation, at a frequency consistent with recovery time and recovery point objectives, and it requires protection of the confidentiality, integrity, and availability of that backup information. The discussion under CP-9 says mechanisms used to protect integrity include digital signatures and cryptographic hashes. That is a protection requirement. It is not yet a statement that anyone opened the data.
The next enhancement, CP-9(1), is the one that asks for a test. Test backup information, at an organisation-defined frequency, to verify media reliability and information integrity. The discussion is blunt about why: organisations need assurance that backup information can be reliably retrieved. Reliability covers three things, and the control lists them separately: the systems where the backup information is stored, the operations used to retrieve it, and the integrity of the information being retrieved. A job status speaks to the operation that wrote the copy. It does not, by itself, speak to retrieval, and it does not re-check integrity later.
SP 800-34 says the same thing in operational language. Backup copies should be tested regularly to ensure that data are being stored correctly and that the files may be retrieved without errors or lost data. It adds a second test, where an alternate site is in the plan: test the copies at that site so the site can actually use the backup configuration the organisation implemented. A job that succeeded in the primary data centre does not answer the alternate-site question.
The Australian texts set the same bar in plainer words. Information Security Manual control ISM-1515 says restoration of data, applications and settings from backups to a common point in time is tested as part of disaster recovery exercises. The paragraph above that control says the point is to be sure backups can be restored, and to find dependencies before the day they matter. ASD Essentials action PRO-10 says regular testing of backup and restoration procedures is how you show that backups are reliable and capable of meeting defined recovery time and recovery point objectives. A completed job has no recovery time, because nothing was recovered.
There is a cost to pretending otherwise. CP-4 says contingency plan test results are reviewed and corrective actions are initiated if needed. If the only result on file is "job succeeded", the review has nothing to correct until an incident supplies the missing test, at the worst time.
How it works
What a job status actually is
A backup product watches its own work. It records that it could read the source, that it wrote an output, and that it did not hit an error it knows how to name. That record is necessary. SP 800-34's backup section expects a defined frequency, a defined location, and a method, and a job that fails those rules is a failed backup even before anyone talks about restore.
The record is also local to the product's point of view. It usually cannot see a later deletion, a later storage failure, a key that will be missing at restore time, or an application that will reject the contents. CP-9's discussion puts integrity protection on the backup information, and CP-9(1) puts the retrieval test later, on purpose. The write and the read are different controls.
When you file a job report as evidence, quote it narrowly. "Job 18442 for the finance file server completed at 02:14 and reported 1.8 TB read and written, with no error flagged by the backup software." That sentence can be true and still sit beside a copy that nobody has opened.
Delivery is the next fact, and it is still not an open
CP-9(5) is a separate enhancement: transfer system backup information to the alternate storage site in an organisation-defined time period and at a transfer rate consistent with the recovery time and recovery point objectives. The discussion says the transfer can be electronic or a physical shipment of media. CP-6 requires an alternate storage site that can store and retrieve backup information, with controls equivalent to the primary site. A copy that exists only on the server that just failed is not the copy CP-6 is describing.
Confirming delivery means checking the store you named in the plan: the object or volume is there, the size is the size the job claimed, and the identity (name, time, system) matches the catalogue. SP 800-84's sample system-test validation includes validating local and offsite data storage and retrieval procedures, as a distinct item from verifying that restoration functions. Storage can be right while restoration is wrong, and the sample treats them as separate lines.
A hash computed by the sender and checked by the receiver belongs in this layer when what you hashed is the object that moved. NIST SP 800-53 CP-9 names cryptographic hashes and digital signatures as mechanisms to protect backup integrity. A match against a protected, trusted reference supports the statement that the bytes received match that reference. A digital signature also requires a trusted verification key; an attacker-controlled checksum beside an altered backup is not an integrity guarantee. It does not support "the application will accept this file". A perfectly hashed copy of a half-written file is a perfect copy of a bad file. The hash did its job.
Opening the data is a retrieval operation
CP-9(1)'s discussion splits reliability into independent tests. One example, offered as an example, is to decrypt and transport a random sample of backup files from the alternate or backup site and compare them with the same information at the primary site. Read that carefully. The sample is decrypted, so encryption was in the path. It is transported from the backup site, so the test uses the copy that would exist after the primary site is gone. It is compared with known information, so "it opened" has a reference, not a vibe.
You will not always have the primary copy still available. After a real loss you cannot compare with production. That is why the control also allows specialised tests of each aspect, and why CP-9(2) asks for something stronger than a byte compare: use a sample of backup information in the restoration of selected system functions as part of contingency plan testing. The discussion says the organisation needs assurance that system functions can be restored correctly and can support the mission. The sample size is chosen from the assurance you need. A single small file from a multi-terabyte system can be a start. It is a weak sample if the functions that matter were not in the sample. Write down what the sample was, and what it leaves out.
SP 800-34's reconstitution section describes the content check in the same spirit. Validation data testing means testing recovered data to ensure files or databases have been recovered completely and are current to the last available backup. Validation functionality testing means verifying that system functionality has been tested and the system is ready to return to normal operations. "Completely" and "current" are judgments against the last backup, not against a job status code.
Application use is stricter than "a file copied"
ISM-1515 does not say "a file was copied back to a disk". It says restoration of data, applications and settings, to a common point in time. PRO-10's testing action is about backup and restoration procedures meeting a recovery time and a recovery point. A copied file can satisfy a technician and miss both.
For this article the practical line is:
- If the thing you backed up is a document or a static file, opening it in the application that owns that format is the content check. A checksum match is the container check that comes first.
- If the thing you backed up is an application and its data, the content check is a function: a login, a report, a message send, a batch that reads the restored data. Pick the function in the test plan. SP 800-34 says a test plan should examine selected elements against explicit objectives and success criteria.
- Settings count. A restored program that cannot find its configuration, its certificate, or its service account has not restored the system the manual describes. This article does not provide commands for repairing those settings. It says the test is incomplete while they are unexamined.
System-level information, in CP-9's discussion, includes system state, operating system software, middleware, application software, and licences. User-level information is the rest. A job that backed up user files and reported success has said nothing about licences or system state. If the recovery plan needs those, they need their own retrieval test.
Where incremental jobs fool the status page
SP 800-34 describes three common methods. A full backup captures the selected files. An incremental backup captures what changed since the last backup of any type, and a restore can require media from several runs: the last full backup and each later incremental. A differential backup captures what changed since the last full backup, so a restore may need the full backup and the latest differential. A successful incremental job is a true report about that night's changes. The restore still needs every earlier piece the method depends on. If any earlier piece fails to open, the successful incremental cannot finish the recovery. The way you notice that is to restore, not to re-read the incremental job's status.
That dependency is the bridge to retention design. Here it is enough to record, for every "we verified the backup" statement, whether the test restored a full copy alone or a chain. A chain that was not walked was not verified.
What to choose and why
Choose the deepest check you can run on a schedule, and keep the shallower checks as daily hygiene rather than as the assurance record.
Use job monitoring every run. Alert on failures, on runs that did not start, and on sizes that collapse without a known cause. SP 800-34 expects frequency and location to be defined. A silent job is not a successful job. Do not archive the green status as a restore test.
Use a delivery check on the store named in the plan, including the offsite or alternate copy where CP-6 or CP-9(5) is in scope. Compare identity and size. If you use hashes or signatures, check them on read-back from that store, not only on the server that created them. CP-9(8) adds cryptographic protection against unauthorised disclosure and modification, and its discussion says key management has to be considered where encryption protects data at rest. A delivery check can confirm that an encrypted object is present without holding its key. If a retrieval test is supposed to decrypt it and cannot, that retrieval test has failed. Record the key's availability as part of the result. Do not print key material in the evidence pack.
Use an open on a sample, at a defined frequency, from the copy you would actually retrieve. CP-9(1) leaves the frequency to the organisation. CP-9(2) ties the sample to contingency plan testing. ISM-1515 puts restoration inside disaster recovery exercises and wants a common point in time across data, applications and settings. PRO-10 wants the test to be capable of speaking to the recovery time and recovery point. A sample that is never timed cannot do that. Write the start time, the time the function worked, and the timestamp of the backup generation. Record both the simulated disruption time and the latest application-consistent data point actually recovered. Their difference is the potential data-loss interval to compare with the recovery point objective. Backup completion time alone may not identify the recovered transaction boundary. The elapsed time is the recovery-time evidence for the scope you actually restored, not for the whole enterprise.
Match depth to consequence, using SP 800-34's ladder as a design aid rather than as an Australian legal category. In Table 3-6, testing backup information for media reliability and integrity is marked not applicable at low impact and applicable at moderate and high impact. High impact adds the expectation that sample backup information is used and that copies are stored in a separate facility. If you have classified a system as low impact under that US scheme, say so, and still read ISM-1515 and PRO-10 before you decide a job status is enough. Those Australian texts do not offer a "low impact, do not open the data" exemption in the passages opened for this article.
A minimum record for one open, hypothetical and short:
- System and function: finance file service, open the month-end workbook.
- Copy: backup dated 10 November 2026, 02:14, read from the offsite store, not from the live disk.
- Chain: full backup only, or full plus named later copies.
- Integrity: hash recorded with the copy matched on read-back, or the comparison was not done and is marked not done.
- Open: workbook opened and the expected sheet total matched the figure stored with the test plan.
- Clock: read started 09:00, workbook usable 09:37.
- Out of scope: the finance application server and its settings were not part of this sample.
That record can sit in the after-action material SP 800-34 already asks for. It cannot be replaced by a screenshot of a green tick with the scope cropped out.
Risks and limits
The attractive risk is double counting. The job succeeded, the object landed, and the hash matched, so three tools agree. They agree about the container. CP-9(1) still wants retrieval and integrity of the information, and CP-9(2) wants selected functions restored. Three container checks are one layer.
The second risk is testing a copy production would not get. The CP-9(1) discussion example starts at the alternate or backup site. An open that uses a snapshot still sitting on the production array answers a useful engineering question and a different claim. Label the path.
The third risk is a sample that avoids the hard files. CP-9(2) says the sample should exercise the selected functions thoroughly enough for the assurance you need. Opening a readme file in a backup of a database server does not exercise the database function. This article does not include database engine procedures. It does say the function in the test plan has to be the function the business would miss.
The fourth risk is declaring the recovery point from the job schedule instead of from the copy that opened. If the schedule says nightly and the copy that opened is four days old because newer copies failed the open, the recovery point you have proved is four days. PRO-10's testing action is about meeting the defined objective. A defined objective you did not meet is a finding, which CP-4 says should become corrective action.
The fifth risk is encryption you cannot reverse. CP-9(8) and the CP-9 discussion put cryptographic protection and key management on the backup. A hash of ciphertext proves the ciphertext. The open requires the key, the tool, and the format. If any of those is missing, the job can still be green.
SP 800-34's media examples include tape. The behaviour to keep is retrieval without errors or lost data, including at the alternate site if you have one. The September 2026 manual and the 15 October 2026 Essentials page are the Australian texts used here. Essential Eight maturity scores are not treated as a current target. The transition guidance published the same day says those scores do not automatically carry over, while restoration testing remains something existing exercises can evidence.
This article was written with AI assistance. It is source research. No job was inspected and no restore was performed. The factual claims have been independently checked against the cited sources. It is not a product manual and it states no vendor's console behaviour.
Sources
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, 11 November 2010, https://doi.org/10.6028/NIST.SP.800-34r1 — sections 3.4.2, 3.5.1 and 4.4, and the backup-testing paragraph in the backup-methods section. Opened 11 November 2026.
- NIST SP 800-84, September 2006, https://doi.org/10.6028/NIST.SP.800-84 — sample system-test validation covering integrity checking, storage and retrieval, and restoration. Opened 11 November 2026.
- NIST SP 800-53 Rev. 5, https://doi.org/10.6028/NIST.SP.800-53r5 — CP-4, CP-6, CP-9, CP-9(1), CP-9(2), CP-9(5), CP-9(8). Opened 11 November 2026.
- ASD, Information security manual, September 2026, https://www.cyber.gov.au/ism/2026-09 — ISM-1515 and the testing paragraph above it. Opened 11 November 2026.
- ASD, Essentials for enterprise IT, 15 October 2026, https://www.cyber.gov.au/publication/essentials-for-enterprise-it — PRO-10. Opened 11 November 2026.
- ASD, Transitioning from the Essential Eight, 15 October 2026, https://www.cyber.gov.au/publication/transitioning-from-the-essential-eight — maturity ratings do not automatically translate. Opened 11 November 2026.
This article was originally published on .