Whether it be due to a hard drive failure, a bad rollback, a ransomware attack, or a natural disaster, the need for data recovery is always going to strike, ready or not. Here are some common questions you should be asking about your backups and data recovery plan for SOLIDWORKS PDM:
What type of backups do I need?
A SOLIDWORKS PDM environment has three major components that work together. Each part Is important to the recovery of the system.
PDM Database in SQL: This is the brains of the PDM system. It knows all the names, references, and metadata for all your files. This backup is performed with the SQL Management Studio. (For more information on performing this backup, refer to chapter 10 of the PDM installation guide: Backing Up and Restoring File Vaults) For automating this type of backup, PDM Professional/SQL Standard users can use the Maintenance Plan tools in SQL Management studio to schedule these. For PDM Standard/SQL Express users, you will have to go with a third party tool: (Like this Microsoft KB solution)
Archive Files Backup: This is the storage of the PDM system. It consists of all your files in a structure that is easy for the database to read (but impossible for anything else). This is simply a copy of the 16 Archive folders defined as the root folders of the archive server.
Archive Settings Backup: This is the connection between the database and archive files. This backup is performed with the Archive Server Configuration Tool. (For more information on performing this backup, refer to chapter 10 of the PDM installation guide: Backing Up and Restoring File Vaults)
How often should I back everything up?
As a rule of thumb, we would advise to have the following:
- A nightly backup of the PDM database from SQL
- A weekly full backup of the Archive Files
- A nightly differential backup of the Archive Files
- A nightly backup of the Archive Server Settings
An important point to keep in mind when scheduling backups, is timing is key:
- Take your daily backups after hours, as the backup could adversely affect the performance of the server while it is running
- Take your database and archive backups at a relatively close time to capture the same amount of data (If this is done after hours, this generally shouldn’t be a problem)
- When recovering, make sure to use the database and archive backups from the same night. Mixing and matching will just lead to errors and problems in the system
Where should I back everything up?
One of the most devastating realizations after an incident leading to a need for data recovery, is finding out that the backups were also destroyed in the same incident. While it might be okay to take nightly backups on the same hard drive to protect yourself against a user error or bad rollback, taking weekly, monthly, or quarterly backups to an offline or offsite location will help protect you against the rare, but more detrimental incidents. Consider the following:
Backup to another Drive: Oftentimes, the incident that leads to data recovery is the result of hard drive failure. Having a secondary drive where your backups reside will allow for an easy recovery if this happens
Backup to another Server offsite: A natural disaster or more extreme hardware failure can turn your server and all your proprietary data into a very expensive doorstop. Having a recovery option offsite will allow you to still recover even if your whole site is destroyed
Backup off Network: Ransomware attacks are becoming more and more common every day. These attacks can hit your entire network and force you to either pay large sums of money to get your data back or start from scratch. Having a backup to an external drive, tape, or secure cloud service will keep your data accessible to you, even in the worst-case scenario.
But, I take snapshots of my virtual machine, I’m fine, right?
Taking a snapshot of the virtual machine that your PDM Environment resides on is a great tool to recover with in certain situations, but just like any other single recovery plan, it can have some major flaws.
SQL is a live database: While users are working in PDM, they are constantly writing data to several temporary tables in the database. If the snapshot was taken in the middle of a transaction, it might have grabbed bad data that it is not able to recover properly, leading to problems in the future
Working with snapshots and virtual machines requires knowledge and training: Purchasing a backup software or taking snapshots of a virtual machine is not the end of the line for a recovery plan unfortunately. Setting up a backup software properly, knowing how to recover from the backup, and knowing what to do when a problem arises are all important and necessary to being successful with this software. When there is a need for data recovery, the engineers on the InFlow Technology Technical Support team are here to help get you back up and running, but if the backup is in a format we do not use or recognize, there will be little to nothing we can do to assist.
All or nothing approach: With a snapshot, you are required to rollback or setup a whole machine with the snapshot in order to recover. If you have a user that just needs a few files that they rolled back by mistake, you are forced to choose between taking on a huge endeavor to recover them or having them redo the work.
Okay I’ve got everything, now what?
You’ve gone through all this work to make sure you are prepared, but how do you know your backups are working as they should? The next step is to verify your backups. There are two parts to verifying the integrity of your backups:
- Check to make sure they are being written properly: Once you start your backup/recovery plan, check back in a day, two days, a week, and a month to make sure that your backups are being written properly. Make sure the naming convention isn’t constantly overwriting the previous backup and that any cleaner service you set up is doing its job to not overwhelm your hard drive space with too many backups. Create a reminder to check in to the backups on a quarterly bases.
- Go through a trial disaster recovery in a test system: To make sure your backups are functional, go through a trial run of a recovery every six months to a year. Set up a test machine to restore your database and archive on and make sure the data is good. This is especially important if you are relying on a third-party software to handle your backup needs.
Senior PLM Support Engineer