EngineeringMechanical EngineeringOperations
SOLIDWORKS Backup, Restore & Disaster Recovery
This is the only domain in which a configuration oversight converts directly into irrecoverable loss of intellectual property. It also has the highest rate of undetected failure, because an untested backup is indistinguishable from a working one.
- Group · Operations
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 19 min
01 Where an Administrative Gap Becomes a Permanent Loss
This is the only domain in which a configuration oversight converts directly into the irrecoverable loss of the organisation's intellectual property. It also has the highest rate of undetected failure, because an untested backup is indistinguishable from a working one.
The distinguishing feature of backing up managed engineering data is that it is not one thing. File content, metadata and server configuration live in three places, are captured by three different mechanisms, and are only useful together and consistent with each other. Two out of three is not a partial recovery; it is frequently no recovery at all.
Around that sits a second problem: the artefacts nobody thinks of as systems. Templates, libraries, the administrative image, standards files and the licence configuration all represent substantial accumulated work and all sit on shares that no backup policy was written for.
Backup automation capabilities differ between the two capability tiers, because they use different database editions. Tooling and interface details change between releases. Verify available mechanisms against the administration guide for your release and tier.
02 The Three Vault Artefacts
File archives
Every version of every managed file, held as ordinary files across a fixed set of folders beneath an archive root.
Captured by: any conventional file backup tool.
Missing this: metadata survives describing files that no longer exist.
Archive server configuration
Login definitions, archive paths and vault registration, exported as a discrete settings artefact from the archive server configuration tool.
Captured by: a deliberate export, included in the file backup.
Missing this: a restore requiring manual reconstruction of settings under time pressure.
Vault databases
Every vault database plus the single master database shared across all vaults on the instance.
Captured by: database backup, scheduled or scripted.
Missing this: files on disk with no structure, references, history or permissions.
Archive content and database content must correspond. A database backup taken hours after the archive backup produces a restored vault containing metadata that refers to files never captured, and files with no metadata behind them.
Recovery from that state is possible but requires manual reconciliation — precisely the work nobody wants during an outage, performed by someone under pressure. Schedule both together, and use the vault's log-in blocking control to hold activity for the window where practical.
Two omissions that recur
- The master database. Easy to overlook where there is only one vault, and fatal to a clean restore. It registers the vaults themselves.
- Second and subsequent vaults. A backup routine written when there was one vault, never revisited when a second was added, leaves that vault entirely unprotected. Both its database and its separate archive root are missed.
03 Beyond the Vault
The artefacts most often outside backup scope are the ones nobody classifies as a system. Each represents work that is expensive or impossible to reconstruct.
| Artefact | Where it lives | Cost to reconstruct |
|---|---|---|
| Templates and sheet formats | Shared standards location | Weeks, and the result will not match issued documentation exactly |
| Shared component library | Network folder or vault | Weeks of configuration plus the generated variant set |
| Custom material library | Shared standards location | Days, plus re-verification of every property value |
| External drafting standard | Shared standards location | Days, and deviations will not be reproduced exactly without the record |
| Administrative image and configuration | Image share | Hours to rebuild, but the configuration decisions must be recalled |
| Deployed settings file | Image share | Hours, plus reconstructing which options were locked and why |
| Licence configuration | Licence server | Hours, but requires serial numbers recorded elsewhere |
| Macros and automation | Wherever they were left | Potentially unrecoverable if the author has gone |
| Standards register and documentation | Wherever it was written | Unrecoverable — it is the record of decisions, not a derivable artefact |
The simplest way to bring this collection into scope is to hold all of it under one share — templates, formats, material library, standards file, property tab, macros and documentation — and place that single path in the backup policy.
It also makes the standards register straightforward, because everything is in one place with one owner rather than distributed across locations that accumulated for different reasons.
04 Automation & Scheduling
What the platform gives you
The upper capability tier uses the full database edition and provides native maintenance scheduling, so database backups can be scheduled and monitored through the database engine's own tooling. The lower tier uses the free edition, which has no such scheduling — database backups there must be scripted deliberately and driven by the operating system's task scheduler.
This distinction is not a minor operational difference. Environments that depend on a person remembering to run a backup will have a gap, and the gap will be discovered during a restore. Where native scheduling is unavailable, scripting it is not optional.
A workable schedule
- Daily, outside working hours. Archives and databases captured in the same window, in that order or as close together as practical.
- Log-ins blocked for the window where the working pattern allows. In a genuinely continuous operation this may not be practical, in which case accept a small inconsistency window and document it.
- Archive server settings export at the same time as or immediately after the archive backup. It changes rarely but costs nothing to capture.
- Weekly full, daily incremental for archive content where volume makes a nightly full impractical — provided the restore procedure for the incremental chain has been tested.
- Monitored, with failure alerting. A backup job that has been silently failing for six weeks is worse than no backup, because it produces false confidence.
- Retention defined. How many days, weeks and months of backup sets are kept, decided against how long a problem might go undetected — corruption discovered a month later needs a set from before it.
Many backup arrangements alert on failure and are silent on success. A job that stops running entirely — a scheduled task disabled, a service account password expired, a script path broken by a server move — generates no failure alert because it generates nothing at all.
Check for the presence of a recent, plausibly sized backup set rather than for the absence of an error. This one change catches the most dangerous failure mode in the entire domain.
05 Recovery Scenarios
Not every incident is a total loss. Knowing which mechanism applies to which scenario is what makes recovery proportionate.
| Scenario | Mechanism | Notes |
|---|---|---|
| Engineer wants a previous version of a file | Vault version history | No backup involved. This is routine vault function, not recovery. |
| File deleted from the vault | Vault recovery of deleted items where retained | Depends on configuration. Verify the behaviour before you need it. |
| Workstation lost with files checked out | None | Checked-out work exists only in the local cache. Bounded solely by check-in discipline. |
| Archive content corrupted or lost | Restore archives; reconcile against the database | Requires a database backup from the same point to be clean. |
| Vault database corrupted | Restore database; reconcile against archives | Same requirement in reverse. Sync is what makes it straightforward. |
| Archive server hardware failure | Rebuild server, restore archives, restore settings export | The settings export is what makes this fast rather than exploratory. |
| Total site loss | Rebuild from off-site copies | Recovery time depends entirely on whether it has been rehearsed. |
| Upgrade failure past the database step | Full restore of the pre-upgrade set | Why that backup must be verified before the upgrade, not merely taken. |
General restore sequence
- Step 1Stop client accessPrevent connections before anything is restored, so no work is done against a partially recovered system.
- Step 2Restore archivesArchive folders returned to the same root path as before. The path must match what the settings and database expect.
- Step 3Restore archive server settingsPlace the settings export and apply it through the archive server configuration tool.
- Step 4Restore databasesEvery vault database and the master, from the set matching the archive restore point.
- Step 5Verify before reopeningLog in to the administration tool, browse the vault, retrieve a file, check history. Confirm before users return.
- Step 6Reopen and communicateRestore access, and tell the team what was lost — work checked out at the time, and anything after the restore point.
06 Restore Rehearsal
The only evidence a backup regime works. Everything else is an assumption.
A rehearsal restores the complete set to an isolated test system and confirms the vault opens, files retrieve, and history is intact. It should happen at least annually, and more often after any material change — a new vault, a server move, a change of backup tooling, or a database engine upgrade.
What a rehearsal proves
- The backup sets are actually readable, not merely present.
- Archives and databases are genuinely in sync.
- The settings export contains what is needed.
- The documented procedure is correct and complete.
- How long a real recovery would take — which is the number leadership will ask for.
What it typically finds
- The master database was never in scope.
- A second vault added later was never added to the routine.
- The settings export is months old or absent.
- Archive and database sets are hours apart.
- The procedure assumes knowledge the person restoring does not have.
A small separate vault maintained for testing configuration changes is also the natural restore rehearsal target. One piece of infrastructure covers two obligations, and both are things that otherwise get deferred indefinitely for want of somewhere to do them.
Document the procedure
The person performing a restore may not be the person who designed the backup, and may be doing it at three in the morning. Write the sequence down: the order, the paths, the credentials required, the expected duration, and how to verify success. Store it somewhere that survives the outage it describes — not on the server being restored, and not only in a vault that is currently unavailable.
07 Failure-Mode Assessment
| Exposure | Low likelihood | Moderate likelihood | High likelihood |
|---|---|---|---|
| Severe consequence | ModerateSite loss with verified off-site copies. Recoverable; recovery time depends entirely on rehearsal. | HighArchive and database sets out of sync. Common, and discovered only during a restore. | HighBackups never test-restored. The most frequent condition, and indistinguishable from safety until tested. |
| Moderate consequence | LowSingle workstation failure. Loss confined to work not yet checked in. | ModerateMaster database or a second vault omitted from scope. Predictable and cheap to fix once found. | HighTemplates, libraries and image outside backup scope. Rebuild cost measured in weeks. |
| Contained consequence | LowSingle file recovery. Routine vault history function, not a backup event. | LowBackup job fails once and alerts. Handled by normal operations. | ModerateBackup job stops silently. No alert generated, because nothing runs to fail. |
08 Continuity Checklist
- All three vault artefacts captured. Archives, archive server settings export and every database.
- Master database in scope. Not only the individual vault databases.
- Every vault in scope. Routine revisited whenever a vault is added.
- Synchronised. Archives and databases captured in the same window, with log-ins blocked where practical.
- Automated or scripted. Native scheduling where available; deliberately scripted where the free database edition is in use.
- Monitored for presence, not just failure. A recent, plausibly sized set confirmed to exist, so a silently stopped job is caught.
- Non-vault artefacts included. Templates, formats, libraries, material library, standards file, administrative image, settings file, macros and documentation.
- Off-server and off-site. Copies held on separate infrastructure, with a set moved off-site on a defined cycle.
- Retention defined. Set against how long a problem might go undetected, not just against storage cost.
- Restore rehearsed within twelve months. Full set restored to an isolated system, with the result and duration recorded.
- Procedure documented. Sequence, paths, credentials, expected duration and verification steps, stored where it survives the outage.
- Check-in discipline established. Work in progress returns to the vault at defined points, since no backup protects the local cache.
- Licence serial numbers recorded externally. Held outside the systems they activate.
- Recovery expectations stated. Realistic recovery time known from rehearsal and communicated to whoever depends on it.
09 Frequently Asked Questions
Our IT team backs up the servers. Is that sufficient?
Usually not, and the gaps are specific. A general server backup captures files on disk, which covers the archives, but a database being written to is not reliably captured by a file-level backup — it needs a database-aware backup or a consistent snapshot. The archive server settings export does not exist unless someone creates it. And synchronisation between the archive and database sets is a requirement a general policy has no reason to know about.
The productive conversation with IT is specific rather than general: name the three artefacts, explain the sync requirement, and ask how each is being handled. That usually resolves it quickly, because none of it is difficult once known.
How often should we test a restore?
Annually as a minimum, and additionally after any material change — a new vault, a server move, a change of backup tooling, a database engine upgrade, or a change of administrator. Each of those can invalidate assumptions the previous rehearsal confirmed.
The first rehearsal is the valuable one and almost always finds something. Record the duration as well as the outcome, because recovery time is the number leadership will ask for and an estimate is not an answer.
Can we back up while people are working?
You can, and many environments have to. The compromise is a small inconsistency window: files checked in between the archive capture and the database capture may be represented inconsistently in the restored set.
Reduce it by scheduling both together and as close as possible, and by using the vault's log-in blocking control for the window where the working pattern allows. Where a genuinely continuous operation makes that impractical, document the accepted window so that whoever performs a restore knows to expect and reconcile a small number of discrepancies rather than being surprised by them.
What is a realistic recovery time?
The only honest answer comes from a rehearsal. The variables are archive volume, restore media throughput, whether replacement hardware is available or must be procured, and how well documented the procedure is. Those differ enough between environments that a general figure would be misleading.
What can be said generally is that the documentation and rehearsal are the largest lever. An organisation with a tested procedure and a known-good backup recovers in hours to a day; one working it out during the incident takes days and may not achieve a clean result at all. Measure yours and state it, rather than estimating.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.