When reporting that a backup exists, I also want to record what I have recovered from it. A file on disk and evidence that necessary records can be restored answer different questions.
The public ERP backup is synthetic page memory. This article distinguishes that example, the actual backup and local restore procedure used for this site, and a new independent synthetic restore module. It contains no client records.
The experience is not a company backup server
Pressing backup in the detailed experience serializes quantity, workflow step and scenario into a string retained in the page. Restore validates and reads that string. A separate JSON download is available, but it does not contain company ledgers or all attachments. Reloading removes page memory, so the feature is not described as durable operational recovery.
Its purpose is to show what it means to resume an earlier valid state. The example checks its format, synthetic marker, known keys and valid workflow values. Having pressed a backup button does not establish a real ERP recovery plan. The demonstration and a storage system a company can rely on must be designed and described separately.
A website needs more than a database copy
Published manuscripts live in this site’s database, while original downloads and images live in object storage. Copying only the database can retain a media reference without the file bytes. Copying only the files can lose the relationship to an article and its revision. The actual backup therefore covers editorial records, revisions, policy, relationships, completed media originals and necessary source files.
Credentials are not exported into that same package. Recovery still needs the separately protected authentication material and a documented way to access it. In-progress uploads also differ from completed objects: the program downloads ready objects and reports incomplete uploads separately. This is a defined recovery scope, not a promise to restore every operation in every storage service automatically.
Do not quietly accept a copy that changed during capture
The current program reads database records, downloads media and reads the database again. It stops if the two database snapshots differ. This comparison is not a transaction locking every storage system at one instant. It exposes detectable changes during the capture and provides a reason to repeat the operation when editorial writes have stopped.
Downloaded files receive recorded byte counts and calculated hashes, and source files receive hashes as well. The restore check compares the backed-up bytes against those records. This gives stronger evidence than a manuscript count alone: it identifies the content actually preserved. A completed copy is followed by separate questions about consistency and integrity.
Read the restored row values in a local environment
The actual rehearsal creates the schema and inserts rows into a fresh local in-memory SQLite database. It checks row values as well as counts, recreates additional indexes, triggers and views, checks database integrity and compares media metadata with the object list. I inspected the previous completed rehearsal record as evidence for this article.
That is not an experiment that rolls back the live database. A successful local rehearsal does not establish that domains, service bindings, credentials and business flows have all been brought back into operation. A real cutover needs a defined write pause, preservation of current records, post-switch business checks and a route back if the switch fails.
A matching hash does not establish the author
The new shared module checks byte length, SHA-256, schema and duplicate identifiers before returning a replacement candidate and change counts for fixed synthetic records. Changing the payload alone fails the integrity check. Replacing both a valid payload and its hash can pass. Hash consistency must not be described as trusted origin or permission to restore.
I included that coherent replacement as an explicit demo case. Protected reference manifests, signatures and access control have separate responsibilities. Showing a candidate also differs from replacing current data. The demo revalidates before its separate apply action, which changes only the synthetic list in page memory. It writes neither files nor operational records.
Leave enough evidence for the next recovery decision
For another company, I would first ask what must not be lost, which point it needs to recover to and whose work should be checked afterwards. Record the data actually read, the environment actually restored and the connections not yet tested. Do not invent a recovery duration or acceptable data-loss guarantee that has not been established.
This publication likewise proceeds through public-content and download verification, followed by the site’s full backup and local restore checks. The shared code is an independent implementation of synthetic format, integrity and preview boundaries. It is not a claim of new browser or physical-device testing, client-ledger recovery or production cutover. Keeping those distinctions in the record is part of the implementation work.