Help

Dental Ark Backup and Recovery

Direct answer

Open the Data Safety area, create a timestamped backup ZIP in an approved destination, then select that ZIP for manifest validation. Keep multiple encrypted and access-controlled copies outside the active data directory. Test a full recovery on a separate approved environment using the clinic’s documented procedure.

The current application UI creates backups and validates their manifests. It does not expose a one-click restore action. A validation pass proves that required package structure is present; it does not prove every record, asset, application version, operating system, and recovery step will work.

Backup is included in Community. The unlimited-record and PDF-export Professional capabilities do not control whether the clinic can protect its local data.

Know the live data location

Data Safety displays the current data directory and database path. Record both in the clinic’s recovery document. The active SQLite database is named dental_ark.db; managed assets live under the data directory.

Never test file replacement against the only production copy. Never manipulate the active database while Dental Ark is running unless a documented maintenance procedure explicitly requires it.

Component	Backup package path	Purpose
Manifest	`backup_manifest.json`	Product, app version, schema, creation, file references
Database	`dental_ark.db`	Patients, appointments, visits, records, finance, audit state
Assets	`assets/` when present	Managed images and documents
Configuration	`config.toml` when present	Local application configuration
Recovery note	`README_RESTORE.txt`	Package guidance, not proof of an implemented UI restore

The old Help page named database.sqlite, images/, config.json, and manifest.txt; those names do not match the current package implementation.

Create a backup

Finish or pause active clinic entry at a known boundary.
Open Data Safety.
Review the latest backup time, path, and age.
Choose Backup now.
Select an existing writable output directory.
Wait for the generated dental-ark-backup-YYYYMMDD-HHMMSS.zip.
Confirm the file exists and has a plausible non-zero size.
Record the time, workstation, operator, destination, and any error.

The backend performs a full SQLite WAL checkpoint before writing the package, records a successful backup event, and audits the action. An operating-system copy of a live database folder is not equivalent to this application backup workflow.

Validate the package

Choose Select and validate and open the new ZIP. Current validation:

opens the ZIP archive;
requires backup_manifest.json;
lists package files;
requires dental_ark.db;
checks that the manifest product is dental-ark;
reports app version, schema version, file count, and errors.

Validation result	Meaning	Next action
Passed	Required structure and product identity were found	Store copy, then test recovery
Missing manifest	Package is incomplete or not a current backup	Recreate and investigate
Missing database	No recoverable core database in package	Do not rely on the ZIP
Wrong product	Selected archive is not Dental Ark	Select correct file
ZIP read error	Corruption, truncation, permission, or wrong format	Preserve evidence and recreate

Manifest validation does not hash every asset against a recorded digest and does not open every patient, record, or image. Treat it as a fast structural check.

Use a recovery-point schedule

Choose frequency from the clinic’s recovery-point objective: the maximum data it is willing and allowed to lose. A busy clinic may need more than one backup per day. “Weekly” is not a universal safe schedule.

A practical pattern is:

create a backup before major import, upgrade, migration, or repair;
create one after a material clinical or finance session;
retain multiple recent generations;
maintain at least one copy separated from the workstation;
maintain an offsite copy when policy permits;
test recovery on a defined schedule and after material software changes.

Cloud folders, network drives, USB media, and operating-system backup tools have their own credentials, sync, malware, deletion, versioning, encryption, and residency risks. The clinic owns that configuration.

Store copies safely

Patient data and assets can be highly sensitive. Limit access to named authorized people, encrypt devices and removable media under clinic policy, and document custody. Do not leave an unencrypted ZIP in Downloads, email, personal cloud storage, or an unattended USB device.

Avoid keeping every copy in the active data directory or on the same physical disk. Disk failure, theft, ransomware, accidental deletion, or account compromise can affect colocated copies.

Plan recovery before an incident

The recovery runbook should state:

authorized decision maker;
production workstation and data paths;
expected Dental Ark version and database schema;
source backup and validation result;
separate test environment;
emergency backup of the current damaged or questionable state;
application shutdown and file-handling procedure;
post-recovery validation and sign-off;
rollback path and incident record.

Because the current UI does not expose one-click restoration, do not improvise replacement steps from this public Help page. Use the approved clinic/support procedure for the installed version. Source code includes an emergency-before-restore package path, but that does not make an unsupported manual restore safe.

Test a recovery

Use a separate approved device or isolated environment with no risk to production. Test:

package selection and structural validation;
application and schema compatibility;
representative patient search and identity;
appointment and visit relationships;
draft and confirmed clinical records;
tooth records, treatment plans, and follow-up tasks;
bills, payments, prepayments, refunds, receivables, and ledger totals;
representative managed assets;
audit and status history;
new backup creation after recovery.

Count and sample data using a written checklist. “The app opened” is not enough.

Failed-backup response

If creation or validation fails:

keep the application and current data unchanged;
record exact error, time, destination, free space, permission, and version;
do not delete the last known-good backup;
retry to a different approved local destination when safe;
validate the new file;
escalate repeated database, archive, or storage errors;
assess whether clinic entry should pause under the recovery policy.

Backup QA checklist

Data directory and dental_ark.db path are documented.
ZIP was created through the application workflow.
File exists outside the active data directory.
Manifest validation passes.
Multiple generations exist.
At least one copy is separated from the workstation.
Storage is encrypted and access controlled.
Recovery runbook identifies owner, version, schema, and rollback.
Full recovery is tested on an isolated approved environment.
Clinical, finance, asset, and audit samples pass.
Recovery test result and next test date are recorded.

Use the clinic setup quickstart and daily workflow to connect data protection with operations.

FAQ

Does “validation passed” mean the backup is fully recoverable?

No. It confirms required package structure and product metadata. Only a controlled full recovery test can validate the wider procedure.

Can I restore from Data Safety?

Not through a current one-click UI action. The screen offers backup creation and manifest validation. Use an approved version-specific recovery procedure.

Should I store the ZIP beside the live database?

Not as the only copy. A failure or compromise affecting the workstation can affect both. Keep separated, protected generations.

Direct answer and acceptance boundary

For “Dental Ark Backup and Recovery”, the short answer is: Create, store, validate, and test Dental Ark clinic backups while distinguishing manifest validation from a controlled database recovery. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in Dental Ark.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: Dental Ark Backup and Recovery

Treat “Dental Ark Backup and Recovery” as a separate acceptance gate for “Dental Ark Backup and Recovery”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: Create, store, validate, and test Dental Ark clinic backups while distinguishing manifest

Verify “Create, store, validate, and test Dental Ark clinic backups while distinguishing manifest validation from a controlled database recovery.” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Direct answer

For “Direct answer”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Know the live data location

Use “Know the live data location” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Create a backup

When “Create a backup” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: Validate the package

Close “Validate the package” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: Use a recovery-point schedule

Treat “Use a recovery-point schedule” as a separate acceptance gate for “Dental Ark Backup and Recovery”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: Store copies safely

Verify “Store copies safely” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: Plan recovery before an incident

For “Plan recovery before an incident”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Test a recovery

Use “Test a recovery” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
Dental Ark Backup and Recovery	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Create, store, validate, and test Dental Ark clinic backups while distinguishing manifest validation from a controlled d	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Direct answer	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Know the live data location	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Create a backup	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Validate the package	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: