Layout, Configuration, and User-View Backups

6.4 Layout, Configuration, and User-View Backups

6.4.1 Objects and Dependencies

Back up layouts, external resources/reports, permissions, synchronization entries, and personal layouts in addition to the database. Embedded reports travel with the saved layout; external .repx does not. Saving a layout does not back up the database or all current CDPS user settings.

Associate program version, release time, database batch, and users with each backup. Restoring an old layout may restore old accounts/data scope, requiring review before reopening.

6.4.2 Offline Backup Procedure

Save/verify CDPS and release state, notify COC users, stop automatic printing, reconcile queues, and exit normally so settings finish saving. Copy inventory items under original names/hierarchy. For synchronization include publishing source and .clcf, not only a downloaded client copy. Associate database/photos, check files/sizes/hashes, and store restrictively.

In the StaffCard example, copy Layouts, Photos, Reports, Database, and existing root settings into RuntimeConfig. Unused features may have no directories; do not create empty settings to make a checklist look complete.

Compare source/backup Properties counts and sizes and, for important files, SHA-256:

Get-FileHash 'E:\CREVIABackup\StaffCard\2026-10-15_1800\Layouts\StaffCard.skdCard' -Algorithm SHA256

Compute the source the same way and compare. Copies must be real files, not shortcuts; follow links/shared references to their actual contents. Do not clean the source before completion. Hashes detect copying/version errors, not business correctness, and do not replace software signature/licensing checks. Regenerable download caches are not business backups.

6.4.3 Restoring Settings and Personal Layouts

Back up destination settings first and exit programs. Restore version-compatible business configuration, not an entire old program folder over a new installation. Prepare the validated database/photos, restore layouts/reports, then matching RuntimeConfig names. Preserve conflicts separately instead of merging all history indiscriminately.

Start CDPS, open the recovery layout, test/adjust new database/photo paths, and save a copy. Then log into COC and manually inspect records/previews before enabling output. Use isolated synchronization or an ordinary layout copy in exercises, not the production publishing source.

User views check user/layout identity. A present but unmatched file may not load; do not edit encrypted data. Recheck columns/photos/grouping after language or schema changes. Default-looking views do not mean missing personnel.

Keep automatic jobs off after restoring printer/imposition/rules. Verify local device, stock, copies, filters, and writable fields, then trial a few records. Another station's port, driver name, or alignment is not automatically valid here.

6.4.4 Machine and Directory Migration

Install official programs/runtimes/drivers and complete licensing before restoring business files. A copied license is not a machine-change request. Update sources, paths, interfaces, fonts, naming, shares, and defaults through normal settings and republish. Windows usernames, application users, and configuration directory names are not interchangeable.

Validate read/write, roles, and physical output before retiring the old station, then handle its personnel data/backups under policy. Do not validate migration by enabling identical automatic-print rules on both machines.

6.4.5 Schedule and Recovery Exercises

Use daily/weekly/monthly retention in 6.3.1 and add immediate configuration/layout backups after major changes. Monthly, restore a recent daily backup; quarterly, also test an older monthly backup.

Restore files/database, connect a layout copy, log in, inspect samples, save/reread a test record, close, and reopen. Include a photo, missing photo, long/special-character content, and a restricted user whose excluded data must remain hidden. Do not practice deleting production people.

Record time, missing dependencies, and outcomes. File presence, decompression, and hashes are partial evidence; correct reopening, data, and permissions establish meaningful recovery.