Before relying on a delivered backup, confirm its recovery-point identity, exact object/file, completeness and integrity, then rehearse recovery on an isolated destination. Test a ZIP archive’s members even when no producer hash exists, but do not confuse a valid archive with proof that the correct data or recovery point was supplied.
NetLeverage’s current Backup & Recovery page describes delivery or synchronisation to customer-controlled S3 or SFTP destinations and zipped copies. That published description supplies context only. This article does not claim that the service automatically produces a checksum manifest or performs the tests below.
All procedures are source-researched and untested. No storage account, destination, customer backup or credential was accessed. Amazon S3 documentation applies to Amazon S3; another S3-compatible service needs its own verified behaviour.
Define the recovery set before inspecting the destination
Identify the protected workload, required recovery point, delivery job and expected files. Record whether the delivery is a complete archive, one component of a larger set, or a copy that depends on separate metadata, log backups or keys.
Use a manifest produced from the actual delivery scope. Include non-secret identifiers, expected object or file names, sizes, completion evidence and any documented checksum algorithm and value. Do not invent missing manifest fields because they would make the verification easier.
Distinguish the recovery-point time from the transfer start, transfer completion and destination modification time. A file delivered today can contain an older recovery point. Destination timestamps alone cannot establish the age of recoverable application data.
For SQL data, identify the format precisely. Native SQL backup sets, database files and a VM image require different recovery procedures. An archive containing database files does not automatically provide a native full/differential/log chain.
Establish independent retrieval access
Test using the approved recovery role and documented access path. Determine whether the destination remains available when the original backup server or its usual administrator is unavailable. A copy in another location can still depend on the same unavailable credential store.
For S3, record the bucket, key and version identifier where versioning is used. The same key can refer to different versions over time. Retrieve the exact version selected for the test rather than assuming the current object is the intended recovery point.
For SFTP, identify the approved server, directory and server-identity verification procedure. OpenSSH’s SFTP manual documents transfer over encrypted SSH transport. Encryption protects transport, but the recovery process must also establish that the client connected to the intended destination under its approved trust configuration.
Keep credentials and private keys out of the evidence packet. Record the role and custody reference instead. If independent retrieval fails, report the missing access dependency even if the delivery job itself has remained successful.
Confirm completeness before hashing
Compare the expected set with the destination listing. Check names, object versions where applicable, lengths and the job’s terminal result. A directory containing some files is not proof that the full delivery completed.
A matching length is a useful check, but it does not establish matching contents. An unexpected length requires investigation before extraction or recovery. Preserve the source manifest and destination metadata so that a later overwrite does not erase the discrepancy.
Ensure the selected copy is complete and stable before comparing it. A destination file still being written is not a suitable verification target. The delivery product’s completion protocol and the underlying transfer mechanism determine how this should be established.
Do not rename a partial file to make it look complete or combine pieces from different recovery points. If the format uses several components, preserve their relationships and obtain the supported reconstruction procedure.
Use checksum evidence with the right meaning
A checksum is a value calculated from data. Comparing values produced with the same documented algorithm over the same bytes can detect a mismatch. The comparison needs a trustworthy expected value and a clear definition of what was hashed.
Amazon documents checksum support for uploaded, downloaded and stored objects in its integrity guidance. Check the actual object metadata and client behaviour. Do not assume every historical upload has the same checksum fields or that every client validates them automatically.
The S3 Object API reference explicitly warns that an ETag may or may not be an MD5 digest of the object. Multipart uploads and some encryption arrangements change that interpretation. Do not compare a local whole-file MD5 with an arbitrary ETag and call either a mismatch or a match conclusive without confirming the documented case.
Also distinguish a full-object checksum from a composite checksum. The API exposes that distinction S2. A value calculated from multipart components cannot be treated as the same calculation as a local hash over the complete downloaded archive without the appropriate documented method.
For SFTP, do not assume the transfer protocol supplies an application-level expected hash. If the producer provides a protected manifest, compare the retrieved file against it using the specified algorithm. If no trusted expected value exists, record that limitation. Hashing the downloaded copy alone creates a reference for later comparison, not proof that it matches the original.
Inspect delivery evidence without altering the remote copy
Untested AWS CLI v2 examples for an Amazon S3 general-purpose bucket R1, R2. Substitute the approved bucket, key and exact version ID. Use existing list-version and object-version read permissions; checksum retrieval for SSE-KMS objects can additionally require KMS permissions. Do not widen access merely to complete a test.
aws s3api list-object-versions --bucket example-recovery --prefix LabOrders.zip --output json
aws s3api head-object --bucket example-recovery --key LabOrders.zip --version-id VERSION_ID --checksum-mode ENABLED
A prefix can match several keys: choose the exact key and version, including whether a delete marker is current. Retain complete paginated results. Compare ContentLength, version identity, checksum algorithm and ChecksumType; absent checksums are a limitation, not a pass. A composite checksum cannot be compared as a simple whole-file digest.
In an already authenticated OpenSSH SFTP session, ls -l /recovery/LabOrders.zip shows the remote listing and size S3. Before trusting that session, compare the presented host-key fingerprint with one obtained from the destination owner through a separate trusted channel R3, R4. An unexpected changed key requires investigation, not disabled host checking.
On an approved recovery workstation, these untested checks read an already downloaded file. Windows PowerShell 5.1 Get-FileHash calculates SHA-256 R5; compare it with a trusted expected value, if available. Python 3's ZIP test reads/decompresses archive members and checks recorded CRCs and headers without extracting files R6:
Get-FileHash -LiteralPath 'D:\RecoveryLab\LabOrders.zip' -Algorithm SHA256
python -m zipfile --test 'D:\RecoveryLab\LabOrders.zip'
Allow sufficient CPU/time and use an isolated workstation for untrusted archives. Unsupported compression/encryption or any CRC error is an unresolved result. A CRC pass detects certain corruption relative to the archive's own records; it does not authenticate the producer or establish application consistency.
For multipart uploads or Part Copy, S3's ETag is not an MD5 digest, regardless of encryption S2. Amazon also documents S3 Batch Operations Compute checksum for at-rest full-object checksums S1, R7. That creates a separate job with its own permissions and report output; review applicable AWS charges before approval. It is not a read-only metadata query, and no job creation is supplied here. AWS's documented default CRC64NVME does not establish which algorithm a particular delivery client used.
Handle interrupted transfers deliberately
Preserve the partial file and failure record under controlled names while deciding whether resumption is supported. Confirm that the remote source has not changed since the partial copy was created.
OpenSSH’s SFTP manual warns that resumed downloads assume the existing local portion matches the remote file; if the remote contents differ, the resulting file is likely to be corrupt S3. A familiar filename is not sufficient evidence that the assumption holds.
Use the delivery product’s supported retry or restart process. Do not assemble a recovery archive by appending bytes from a later export to an earlier partial copy. After any retry, repeat the completeness and integrity checks for the final selected file.
This article supplies no transfer command with credentials, no overwrite script and no automatic deletion step. The exact source, destination, version and local output path must be reviewed before a test retrieves potentially sensitive data.
Extract into an isolated, adequately sized destination
Use a supported archive tool and a new test directory with appropriate access controls. Inspect the archive’s contents before extraction. Confirm that filenames and paths fit the expected recovery set and do not target existing application data.
Budget for the archive, extracted data and working space. Compression means the downloaded file size is not the amount of space required to extract or restore it. A successful transfer to a small recovery workstation can still leave restoration impossible.
If the archive is encrypted, obtain its required recovery secret through the approved process. Keep that dependency separate from S3 encryption, SSH authentication and database TDE keys. Satisfying one does not establish that all protected layers can be opened.
An extraction test checks the archive layer. It does not prove that the contained database is consistent or that the VM can supply the business service. Preserve extraction warnings and missing components rather than proceeding with an incomplete result.
Perform a bounded recovery test
Choose the correct recovery procedure for the contained format and use a separate destination. Keep restored identities, scheduled jobs, email and integrations isolated from production. The test must not accidentally turn a recovered copy into a second live executor.
Validate known synthetic records or an authorised reference set through the application. Confirm the expected recovery point and document missing later work. For a file recovery, verify relevant contents and the application’s ability to open them; for SQL, include the DBA’s integrity and application checks.
Record retrieval, integrity checking, extraction, restore and application acceptance as separate milestones. If an archived storage class requires a retrieval preparation step, include it in the recovery design rather than claiming the object’s existence means immediate access. The S3 object documentation identifies restoration requirements for some storage classes S2.
Keep the original delivered copy intact throughout the test. Cleanup should remove only identified test outputs after evidence retention is agreed. It must not alter the source backup or unrelated destination versions.
Report what was actually demonstrated
Use precise outcomes: correct set located, exact version retrieved, checksum comparison passed where supported, archive extracted, application recovery accepted. Mark unavailable checks as unknown, with the reason.
A hash match does not demonstrate business consistency, and a successful application sample does not validate every file or every retained recovery point. State the selected scope and repeat the verification through an owned operational process when material inputs change.
Limitations
Examples cover Amazon S3, OpenSSH SFTP, Windows PowerShell 5.1 and Python 3, not every compatible service or archive format. They are unexecuted. Remote reads can incur charges; archive tests consume resources. No checksum proves a complete application recovery without the recovery test.
Acceptance checklist
- Exact recovery point, key/version and expected files identified.
- Independent retrieval and destination host identity established.
- Size, trusted hash where available, and archive test recorded separately.
- Isolated extraction and application recovery accepted with remaining limitations.
Learning notes
- Delivery time and the age of the recovered data are different measurements.
- An S3 ETag is not a universal whole-file checksum.
- Retrieved bytes, an extracted archive and a usable application are separate acceptance stages.
Related reading: SQL Point-in-Time Restore: Plan and Verify the Backup Chain; Restore a TDE Database Without the Original SQL Server; Scheduled Jobs After Migration: Prevent Duplicate Work; Size Backup Retention Using Measured Storage Growth.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- Checking object integrity in Amazon S3 - Amazon Simple Storage Service
- Object - Amazon S3
- sftp(1) - OpenBSD manual pages
- Cloud Backup & Recovery for Business Data | NetLeverage
Additional revision sources:
- list-object-versions : AWS CLI 2.39.2 Command Reference
- head-object : AWS CLI 2.39.2 Command Reference
- ssh(1) - OpenBSD manual pages
- ssh_config(5) - OpenBSD manual pages
- Get-FileHash (Microsoft.PowerShell.Utility) - PowerShell | Microsoft Learn
- zipfile : Work with ZIP archives : Python 3.15.2 documentation
- Compute checksums - Amazon Simple Storage Service