Backups, Backups, Backups

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, whether you’re ready or not. Here are some common questions you should be asking about your backups and data recovery plan when backing up 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.

1. PDM Database in SQL

This is the brain of the PDM system. It knows all the names, references, and metadata for all your files. You can use SQL Management studio to perform this backup. (For more information on performing this backup, refer to chapter 10 of the PDM installation guide: Backing Up and Restoring File Vaults) If you want to automate 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)

2. 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.

3. Archive Settings Backup

This is the connection between the database and archive files. You use the Archive Server Configuration Tool to perform this backup. (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 at least the following:

1. A nightly backup of the PDM database from SQL
2. A weekly full backup of the Archive Files
3. A nightly differential backup of the Archive Files
4. A nightly backup of the Archive Server Settings

An important point to keep in mind when scheduling backups is timing is key:

1. Take your daily backups after hours. This is because the backup could adversely affect the performance of the server while it is running
2. Take your database and archive backups at a relatively close time to capture the same amount of data. Generally, this is not a problem if you do it after hours.
3. 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. However, 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 you get a snapshot in the middle of a transaction, it might grab bad data that it can’t recover properly. This can lead 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:

1. Check to make sure they are being written properly.
   1. 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.
2. Go through a trial disaster recovery in a test system.
   1. 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.

***This post was originally posted by Tyler Harmon, Sr. PLM Support Engineer***