lastcopy

Evidence report sample

Get this for your backups

db01 nightly pg_dump · 8 Jul 2025 to 7 Jul 2026 (UTC) · generated 7 Jul 2026, 14:02 UTC

Expected every 1d with 1h grace. RTO 1h. Hand this to your ISO 27001 or SOC 2 auditor as the restore-testing register for this system.

Timestamps are assigned server-side by Lastcopy on arrival. The register has no edit function. This is a sample with generated data, showing exactly what your auditor receives.

99.5%coverage
(363 received + 1 unobservable of 365 expected check-ins, service window disclosed below)
1explicit failure
2anomaly alerts
1missed-deadline alert

Assurance statement

Each tier states exactly what it proves, and no more.

TierWhat it provesStatus in window
Ran Timestamped check-ins were received from the backup job on schedule, with reported metrics within learned norms. 99.5% coverage, 2 anomalies, 1 failure
Verified A repository integrity check (restic check --read-data-subset, rotated slices) ran and reported its result. 52 verifications reported, last pass 5 Jul 2026
Drilled An actual restore was performed on the operator's infrastructure and its measured results were reported. 4 drills reported, last pass 14 Jun 2026, next due 12 Sep 2026

Restore drill log

WhenResultByRTOReported detailFrom
14 Jun 2026, 09:12 UTC pass adam met 30m 42s within 1h rows_restored=48,214,890 · scope=orders,customers · env=scratch-docker 10.0.4.20
12 Mar 2026, 10:03 UTC pass adam met 29m 21s within 1h rows_restored=44,102,455 · scope=invoices · env=scratch-docker 10.0.4.20
9 Dec 2025, 09:44 UTC fail jamie missed 1h 13m over 1h scope=orders · env=scratch-docker · note=WAL replay slow, storage tier fixed, re-run passed 10.0.4.21
2 Sep 2025, 08:57 UTC pass adam met 28m 18s within 1h rows_restored=39,877,210 · scope=orders,customers · env=scratch-docker 10.0.4.20

Note the failed drill of 9 Dec. A failure with a documented remediation and a passing re-run is stronger audit evidence than a perfect record, because it proves the control operates.

Lastcopy service interruptions in this period

Check-ins sent during these windows could not be received. Silence inside a window is not evidence of missed backups, and it is not counted as coverage either. The expected count above stands in full, and check-ins lost to these windows are reported as unobservable next to it. Our own downtime appears in the register for the same reason nothing else can be edited out of it.

StartEndLengthNote
22 Jan 2026, 01:37 UTC 22 Jan 2026, 02:19 UTC 42 minutes Check-in endpoint unreachable. Check-ins sent in this window may not have been received.

What was caught this year

WhenKindEvidence
18 Apr 2026anomalyBackup size collapsed. bytes = 3.2 MB vs 30-run median 41.8 GB. The job reported success but produced far less data than normal.
18 Apr 2026recoveredCheck-in received again. The job has recovered. (A table lock made pg_dump skip everything. Fixed the same day.)
3 Nov 2025downNo check-in received. Expected one every 1d, and the 1h grace was exhausted. (Cron was disabled during maintenance and restored the next morning.)

Every row above is a timestamped record received from the backup job itself. Full raw data exports as CSV. Watch 6 backups free. No credit card.