SOLIDWORKS PDM Disaster Recovery

Have you got a SOLIDWORKS PDM disaster recovery procedure in place?

Over the last few weeks and months, we have seen a major uplift in the calls coming into the helpdesk asking for our advice and assistance after a customer suffered a cyber-attack that has corrupted all, or part, of a PDM implementation. The purpose of this article is to help your PDM Administrators or IT Professionals understand the steps involved in preparing for and then executing a SOLIDWORKS PDM Disaster Recovery, should you need to rebuild a copy of a PDM vault after your SOLIDWORKS PDM infrastructure becomes inoperable, inaccessible, or damaged as the result of unplanned disasters. This same process could also be used to create a duplicate system to recover individual or small groups of files after an accidental removal from the Vault (destroyed not deleted).

Before starting a recovery, you should make certain that the extent of the infection doesn’t also include your Backup Server(s) or that the infection didn’t occur before the last backup took place. For this reason, offsite backups (tape or cloud) should also form part of your backup strategy.

What to expect from a disaster recovery?

Restoring a Vault from Backup will revert the content of the Vault to the state it was in at the time that Backup was created. Based on the fact that the recovered Vault will only be as good as the last backup, this has a number of key observations:

• Any changed data, not Checked-in, will be excluded from the backup / recovered Vault
• Any new data, that has never been Checked-in, will be excluded from the backup / recovered Vault
• Any data created or modified after the last backup will be excluded from the recovered Vault

As there are a number of key backups required to complete the recovery process it is therefore very important, from an integrity point of view, to ensure that these Backup(s) are created as close as possible to each other.

Most Customers will be creating a single ‘daily’ backup during ‘downtime’ meaning that after a Disaster Recovery they could have lost a maximum of one day’s worth of data. To reduce the amount of data that you would risk losing you could consider running the Backup(s) more frequently, but this is only effective if new and changed Data is being Checked-in throughout the day.
NOTE: the use of Overwrite Latest Version during a Check in can reduce the number of file versions being created in the Archive with more frequent Check In’s.

It is also worth explaining that PDM doesn’t support Transactional Database recovery, so this would mean creating multiple Full SQL backups throughout the day with a Differential Backup of the Archive in parallel to this. A full Daily backup should still be archived to a safe location each day.

** If you are reading this as a result of a Disaster and are already missing thBased on the fact that the recovered Vault will only be e Archive Server Settings, or the ConsisioMasterDB Backup there is still the possibility of a recovery, however you will need assistance from Technical Support in the supply of an ‘application’ that can rebuild the missing Archive Server Registry keys from the Vault DataBase itself. **

Disaster Recovery Checklist

What follows is an overview of what you need to be doing now and what information you may need to have documented to ensure you can complete a full Disaster recovery. View our SOLIDWORKS Disaster Recovery PDF for full details on all of these points.

• Document Your Installation
• Understand And Confirm Your Backup Strategy
• Ensure Your ‘Passwords’ Are Documented And Verified
• Installation Media
• Document External ‘Links’
• Cold Storage
• Message System
• Add-Ins
• Implementing The Recovery Process
• Restore Vault Databases
• Restore Archive Server And File Vault Archives
• Configure The Moved Sql File Vault Database
• Configure The Moved Archive Server
• Updating Client Registry Keys (Local View Settings)
• Updating Web 2.0
• Updating Replication Settings (Pdm Professional Only)
• Firewall Rules
• Other Considerations – Administration Tool

Please note: You should only make changes within the SQL database if you are confident and competent that you can do this without compromising the integrity of the database. If you are unsure, we would strongly recommend that you use our Services to complete this Disaster Recovery exercise for you.

Registry changes should only be made after a backup of existing keys have been taken, and only by IT personal who are comfortable and competent to do so.