TECHNOLOGY / BACKUP / RESTORE / RETENTION
Eligible for Cleanup. Safe to Delete?
Creating a backup: can we get the data back?
Imagine a company with daily backups and a report full of green lights. When the data finally goes wrong, the manager asks for a restore. The engineer replies: “We made the backups. We haven’t tested restoring them.”
It is rather like checking the safe is locked every day, then looking for the key only when you need what is inside. A completed backup still needs a recovery path that can be followed through.
Keepweft is my experimental local SQLite backup and validated-restore controller. Its delivered scope is one registered WAL-mode database, a fixed ledger-v1 demonstration profile, and one managed read-only restored copy. Scheduled backups, age-based retention and production database cutover remain outside the delivered feature set.
It takes a bounded read snapshot, creates a standalone backup through SQLite’s Online Backup API, verifies a fixed application contract, and publishes it in a persistent backup catalog. The source can continue receiving transactions. The backup must identify the snapshot it holds without mixing in later source state. Holding a read snapshot can also grow the source WAL, which makes cancellation and deadlines part of the workflow.
Validating a restore: an intact database is only part of the check
A restore creates a separate copy and leaves the live source in place. Checks cover database integrity, identity, content and fixed application relationships; the managed reader process then performs real read-only queries against the restored copy. This tests the demonstration application’s result. It does not perform production service cutover.
Review found a real false acceptance in an earlier verifier: child items without a valid parent transaction could still pass. SQLite allows a child foreign key to be NULL. The foreign-key check, total counts and grouped item shape did not independently establish that every item belonged to an actual transaction.
The repaired verifier checks parent membership independently. Negative tests through the real controller and worker must reject those databases without publishing a backup. “Validated” therefore has a specific meaning here: the fixed ledger contract. It does not certify every application that uses SQLite.
Backup requests also have persistent deduplication. Clients retain the original request envelope to identify an exact retry. A stale-authority response does not authorize inventing a fresh request ID. Reader mutations use current epoch/revision checks; backup deduplication does not give every operation the same retry semantics.
Using the copy: uncertain occupancy keeps the dependency in place
A managed reader can keep reading after its controller crashes. Losing the control response does not prove that the reader stopped. Keepweft uses a real cross-process guard lock to establish occupancy. A live reader or unresolved occupancy retains the restored copy and the backup’s pin.
The pin records a retention dependency in this managed workflow. Until the restored copy can be safely released, retention must preserve the backup it depends on. This protection covers managed readers and their guards. It does not automatically discover arbitrary external programs opening the files.
A stop request still needs evidence of actual exit. Timeout, a paused reader or a busy guard cannot become a successful stop. After restart, the controller does not kill a process solely by a persisted PID, which may have been reused. Graceful controller shutdown deliberately leaves readers alive too: stop and release them first when a fully stopped deployment is needed.
Once exit and occupancy evidence permit it, current authority and state checks can allow copy release, deletion and persistence steps, followed by removal of the backup dependency. Recovery reconciles interrupted work. A missing file or a changed status label alone cannot establish that the whole release completed.
Retention: eligibility still needs permission to delete
A count policy says how many backups we want to keep. Deleting a particular backup also depends on current references, protection of the latest backup, ownership and state evidence. Becoming a cleanup candidate does not authorize bypassing those checks.
On narrow screens, scroll the table sideways to read all columns.
| What we know | What may happen next | What still matters |
|---|---|---|
| A backup passed its fixed application contract | Create and verify a separate restored copy. | Production cutover has not been established. |
| A reader is alive or occupancy is unresolved | Retain the copy and backup pin; investigate occupancy. | No response does not prove exit. |
| Reader exit and a free guard are established | Release the copy under current authority and state checks. | A stop request alone is not exit evidence. |
| Copy release completed and the backup is unpinned | Reevaluate cleanup eligibility. | Latest-backup and other protections still apply. |
Conservative retention has a cost. A pinned old backup can occupy a slot or capacity and block a new backup. Keepweft protects the latest and pinned backups; when no safe slot is available, it refuses rather than treating occupied capacity as free. Operators must decide how long they can tolerate an older latest snapshot and who will investigate the blockage.
The managed logical-byte budget is a software policy, not a filesystem quota. The source database and its WAL/SHM are outside that budget. Receipts, catalog entries and guard metadata can remain; general online guard/tombstone garbage collection is not implemented. Deleting guards to reclaim space can remove the very evidence needed to establish occupancy.
Retained evidence: 83 tests, 24 cycles and two reboots
These observations come from retained run 21c52afcecce99d5; no VM or hardware experiment was rerun for this article. Native macOS and an isolated Linux VM passed the same 83 tests without failures, errors or skips. Linux used the installed wheel with module and SQLite-runtime provenance checked. The record also includes 10 reader/fault cases, four closeout cases and two normal VM reboots. Sixty-three rejected report corruptions challenge the qualification verifier; they are not 63 product failures.
Twenty-four backup/restore/reader lifecycle cycles completed in one controller process over 124.69 seconds. Each cycle included at least five seconds of live reader dwell and queries on both sides. At cycle boundaries, remaining children, active restores, readers and pins were zero.
Resources did grow. Sampled controller RSS was 21,096 KiB initially, 28,424 KiB after the declared four-cycle warmup, and 30,244 KiB at the maximum/end: a post-warmup increase of 1,820 KiB within the predeclared 4,096-KiB allowance. All raw and quiescent FD samples were seven. These are short Linux VM samples, not continuous peaks, leak freedom or a long-term bound. Retained metadata grew as expected.
Separate receipt and logical-capacity refusals preserved backup files, the complete catalog and receipt contents while allowing query/stop/release. An earlier composite resource check failed without retaining its offending samples; its exact cause remains unknown. The current passing trial does not explain that older failure.
Before each normal reboot, the controller was killed to prevent graceful shutdown from performing recovery for the test. After boot, before starting any controller, catalog and restored-copy contents were checked for unchanged persistence. The service was then started to reconcile a formerly serving copy and an interrupted release. This tests explicit service startup after boot, not systemd autostart or uninterrupted protection throughout boot.
Several copies on one device still share its failure
Imagine a company announcing three copies of every important document.
“Where are they?”
“In the same filing cabinet.”
“What if the cabinet burns?”
The manager pauses: “Can we at least report a 200% increase in backup copies?”
The arithmetic works. The device-loss risk remains. Keepweft’s local copies do not protect against device failure, loss or disappearance of the whole storage location. Off-device/remote backup, encryption, point-in-time recovery, arbitrary schemas, physical-storage behavior, abrupt power loss and production database cutover are outside this qualification. Normal VM reboots cannot stand in for those tests.
This is a local single-controller design with trusted same-UID processes. Its ownership guards do not provide isolation from a malicious process running as that same user, or universal protection against deletion.
Deployment decisions: who can establish that release is safe?
I would agree with operators which reads and data version must be recoverable, who investigates an occupied reader or capacity-blocked backup, and how to preserve state for offline investigation when online reconciliation cannot resolve it.
That requires a practical handoff: who can inspect processes and guards, who can stop services, and which source-data and disk budgets need separate monitoring. Conservative retention consumes space; using an older snapshot carries a cost too. Changing a dashboard label cannot replace those decisions.
For Keepweft, safe cleanup connects creation, verification, use, release and retention. Even after an object becomes eligible for cleanup, deleting it still needs sufficient evidence about its current state.