Administration guide
Keep the printing operation recoverable.
Know which version each service runs, investigate uncertain jobs and preserve the data needed to restore the installation. A useful operating record connects a request to its inputs, destination and reported outcome.
Start with the current operating picture
- Automation Services: inspect connection, applied documents, recent activity and jobs. Being connected does not establish that the latest deployment is applied.
- Print Center and archive: inspect requested quantities and the recorded delivery state. Follow a held or unknown result before requesting replacement labels.
- Automations: read run counts, notices and failures. A finished automation branch can mean a print was requested; inspect delivery separately.
- Distribution: compare the intended pinned version with each service's applied state. Roll out saved changes explicitly.
- Audit: review changes to documents and configuration separately from print history.
Use the printer recovery guide for an interruption and the traceability walkthrough to investigate a particular request.

Back up the actual storage locations
Record OLE_DB_DRIVER, the configured database location and OLE_STORAGE_PATH. The default Windows setup puts openlabelengine.db in the program folder and files in data. Backing up only that subfolder misses the database. With PostgreSQL, preserve a database backup as well as the file store.
| Keep | Why it matters |
|---|---|
| Center database | Document versions, configuration, print archive, audit history and the Center's service-certificate authority. |
| File storage | Referenced artwork, fonts and other stored files needed alongside the database. |
| Original credential master key | Decrypts saved credentials. It comes from OLE_CREDENTIAL_KEY or credential.key in the storage directory. |
| Version and configuration record | Identifies which executable, environment and storage layout belong to the saved state. |
Keep the master-key export separately from the backup and server. A newly generated key cannot decrypt credentials protected by the old one. The database backup also contains the Center's private certificate-authority key, so restrict access to it.
Use the procedure for your installation
The matching source contains scripts/backup.sh and scripts/restore.sh. They require Bash, GNU tar and the applicable SQLite or PostgreSQL utilities. The current Windows ZIP and release image do not include those scripts; the recorded backup/update procedure covers the source Compose setup.
For that procedure, stop Center writers before backing up database and files together. The backup script excludes the credential master key and records checksums and history counts. Restore replaces a complete state; plan it with the original key and the matching version, then verify credential readability.
Update with a return path
Record the starting point
Record
center --version, the API version, service versions and the supplied package details. Check the update instructions for those exact builds.Preserve a consistent backup
Stop the relevant Center writers and preserve database, file storage and the separately held key. Keep the previous executable or image reference.
Apply the update and review the result
Center startup applies database migrations. Check
/healthz, the version, history counts, credential readability and service connections before resuming normal work.Restore the matching state if needed
Returning to an earlier binary may also require its pre-update database and files. Follow the restore procedure; replacing the executable alone is not a database rollback.
The N-2 policy concerns the Runner protocol. New document features can still require newer service capabilities. Check the affected services before deploying them. Automatic service updates are not part of the current implemented update path.
Explore daily print management → · Review service setup → · Discuss your operating setup →