When looking at any design, one of the costliest items involved is creating the design data. Whether that be 3D Models, 2D Drawings or any other supporting documentation, it all takes time to create and therefore has a value. Safeguarding that data should be of paramount importance and members of most organisations will have IT resources that handle this. For smaller outfits (especially contractors) this a task that gets done whenever it is remembered and is seen as more of a necessary evil. (The important word here is necessary).

There are many programs out there to handle backing up of data (Microsoft have their built in Windows Backup for small users, then Backup Exec, Veritas etc. for server backups) but when it comes to Vault there are some issues with backing up the SQL databases, as these are seen as in use files, and unless you have a SQL agent for you backup software, the all important databases will be missing when you come to restore. And if you do have SQL agents, once all files are restored there are permissions and passwords to be sorted out.

Enter the Autodesk Data Management Server (ADMS)  console backup. This gives a dataset that can be easily restored through the ADMS console. When this is done, ADMS sorts out all the permissions and passwords (and can even relocate databases and file stores in the event of disk reconfiguration).

So why doesn’t everyone use ADMS Backup? Well there is one issue and that’s space. The backup dataset consists of SQL backups of the Vault databases, and a replica of the file store, thus a double up of your working data. This can be a stumbling block for many IT resources, as it’s extra “wasted” disk space that could be used for other tasks, or needs to be purchased.

However, when we look at the title of this article, is that disk space more important than the years of design data it could be protecting?

Another factor to consider when planning you data protection is disaster recovery (DR), a subject close to many  New Zealanders hearts with recent earthquake activity. Disaster recovery should be planned for a disaster, so not just replacing a data disk, but an entire server replacement. Simulate this by trying to recover your data to a whole new server (with machine virtualisation these tests are much easier to carry out than before). Not only will this give you a procedure to follow, but it is a good test of your backup validity. Try and run a DR simulation at least once a year, just to keep testing recovery from those backups (usually a really good idea just before upgrade time)

In our next article, we’ll look at Vault backup strategies and scripts, along with some interesting use of batch files.