SOLIDWORKS PDM Backup, Restore, and Disaster-Recovery Checklist

Direct answer

What must a complete SOLIDWORKS PDM backup include?

Back up the vault database, ConisioMasterDb, every physical file-vault archive, and archive-server settings as a coordinated recoverable set. Also preserve the software and service-account information needed to rebuild the environment. In replicated systems, include each required archive location. The backup is not proven until an isolated restore test succeeds.

Protect every component that makes the vault coherent

SOLIDWORKS PDM separates metadata from file content. The Microsoft SQL vault database tracks records and pointers, while the archive folders hold the physical file versions. Archive-server settings hold paths and configuration needed to reconnect those pieces. Backing up only one layer can leave you with content that the database cannot locate or database records whose file versions are unavailable.

The PDM Professional SolidPractices guidance identifies ConisioMasterDb as part of the database backup set. In a replicated environment, archive content may exist across more than one archive server, so the recovery design must state which locations are protected and how replication state is handled. Confirm the equivalent component set for the installed edition and never assume one server contains every required version without evidence.

Create an asset register containing vault names, databases, archive roots, archive-server settings backup, server names, software release and service pack, license dependencies, service accounts, encryption or backup credentials, network paths, and owners. Store sensitive values in approved credential systems, not inside the public runbook.

Set recovery targets from production consequences

Define the recovery point objective as the maximum acceptable data loss and the recovery time objective as the maximum acceptable service interruption. A shop that releases revisions throughout two shifts may need a different schedule than a small engineering group that checks in a few times each day. State the objectives in business terms and let IT design the protected copies and infrastructure around them.

Map failure scenarios separately: client loss, archive-server loss, SQL-server loss, storage corruption, credential loss, ransomware, site outage, and accidental deletion. A synchronized-vault feature or local cache can help with specific user-work cases, but neither replaces server-level backup and disaster recovery.

Assign authority for declaring a disaster, stopping vault access, selecting the recovery point, communicating downtime, approving restored service, and reconciling work created after the chosen recovery point. Technical restoration without a business reconciliation plan can still release the wrong revision.

Keep database and archive copies as synchronized as practical

The official guidance warns that database records and archive content should be backed up together for a clean recovery. One approach blocks new logins and clears active sessions during backup. Another accepts a controlled risk by backing up during low activity. The right choice depends on operating hours, data volume, tools, and recovery objectives, but the chosen tradeoff should be explicit.

Schedule archive-server settings backups when the configuration changes and coordinate them with the archive and database protection. Monitor job completion, duration, capacity, retention, and copy integrity. A dashboard that reports “backup succeeded” should point to the actual vault components and destinations, not only a generic server snapshot.

Keep at least one protected copy outside the failure domain of the production servers and restrict backup deletion or encryption paths according to the organization’s security design. Test whether the recovery team can retrieve the backups and credentials during the same event that removes normal network services.

• Document the exact backup jobs for every database, archive root, and settings file.
• Record whether users are blocked, sessions are cleared, or inconsistency risk is accepted during backup.
• Alert on job failure, unusual duration, capacity pressure, and missed offsite or immutable copies.
• Protect the runbook and credentials without putting passwords in ordinary documents.
• Retain enough recovery points to address corruption discovered after the most recent backup.

Practice restoration on isolated systems

A restore test needs isolated servers, the same SOLIDWORKS PDM version and service pack as production, safe network separation, and owners who understand that a restored vault has identity and replication implications. The official SolidPractices document warns against letting a sandbox attempt to contact production replication partners.

Restore the databases, archive folders, and archive settings according to the approved procedure. Recreate required search or linked-server elements, redirect server references to the isolated environment, create a test vault view, and log in with controlled accounts. The exact sequence belongs in the environment-specific runbook and should be reviewed after software or architecture changes.

Validation must go beyond opening the administration tool. Search for known records, open several file versions, inspect history and state, retrieve a top-level assembly with references, compare expected hashes or file properties, and exercise a check-out and check-in only within the isolated test. Record elapsed time, the exact recovery-point components, every manual dependency, and the business owner who accepted the restored data.

Make the recovery runbook executable under pressure

Write prerequisites, locations, owner contacts, decision authority, server dependencies, restoration order, validation cases, communication steps, rollback or escalation conditions, and evidence storage. Avoid a runbook that says only “restore the latest backup.” The team needs to know which set is synchronized, why it was selected, and how post-recovery work will be reconciled.

Store a sanitized copy where the recovery team can reach it during an identity or site outage. Sensitive credentials and recovery keys should stay in approved protected systems with tested break-glass access. Assign a primary and backup person for every task that cannot wait for a specific administrator to return.

Run a tabletop exercise between technical restores. Walk through a failed SQL host, ransomware affecting production storage, and a discovered archive inconsistency. Tabletop exercises expose missing authority and communication paths, while the isolated technical restore proves that the data and procedure work.

Review recovery after every meaningful environment change

A server move, storage change, PDM upgrade, authentication change, replication change, new vault, or backup-platform replacement can invalidate a previously successful procedure. Add recovery review and a new restore test to the definition of done for those projects.

Report recovery readiness in plain language: last complete coordinated backup, last offsite or immutable copy, last successful isolated restore, measured recovery time, unresolved risks, and accountable owner. Backup volume and green checkmarks are secondary to the question the business needs answered: can the correct production data be recovered within the agreed window?

Frequently asked questions

Vendor references and method

1. SOLIDWORKS PDM Professional Backup and Restore Procedures, SolidPractices, official architecture, backup, and isolated-restore guidance
2. SOLIDWORKS 2026 Help: Backup Settings dialog, official archive-server settings backup controls
3. SOLIDWORKS 2026 Help: restoring backup settings, official settings-restore procedure
4. SOLIDWORKS 2026 Help: preparing to upgrade, official requirement to back up database and archive files
5. Checklists, sequencing, and decision gates on this page are Morphos 3D implementation guidance. Adapt them to the exact software release, infrastructure, machine, controller, quality system, and approved company procedures.