No backup you say .... How many days!?!

Every week I will check a companies server or receive a support call, because they are looking to upgrade or have just noticed they have not had a backup.  This could have been going on for days, weeks or months and no one has checked on the process.  In fact the current record found by our support desk stands at 1549 days without a backup; over 4 years without ensuing that your engineering data and companies IP is recoverable should something happen.  

The reasons for backups not running correctly are many and varied but in my experience here are the top 3 things to check:

1. Has someone left the ADMS console open?  The Vault server console can only have one instance open at a time.  Often a CAD administrator will log onto the server and leave this open which means that the backup can't start.  Adding a process kill command into your script can mitigate this.
   
   
2. Has the server has run out of space?  This happens as the vault size increases however strange as it sounds its not always obvious that this is the cause.  If you check your backup logs and find that you are managing to get a backup every 2 days rather than nightly then I would assume that space is the issue.  This is due to the backup cycling that is scripted into your scripts.  Each night your script runs and deletes a B folder.  It then renames an A folder to B, creates and new A folder and stores the backup in it.  By doing this you always have 2 valid backups.  As you start to run out of space you find that the night's backups doesn't complete meaning the A folder is empty.  The next night the cycling happens and that blank A folder becomes B leaving enough room for a new backup ... hence every 2 nights.
   
   
3. Password changes! My nemesis.  We know that passwords need to be changed regularly however when it comes to admin accounts you need to know what has to be updated as well.  The Vault and associated SQL use many accounts and passwords.  Changes to any of these can and do stop backups from running. 

The main 2 culprits are:

• the password for the account used by task scheduler to run the backup script.
• the password for the Vault administrator account.  A lot of companies don't realise that the vault backup script uses an internal vault account and its password is hard coded into the script file.  If someone changes this password then the script also needs updated.

As a bit of a guide to the various accounts and passwords I've put together the below guide.  For security reasons I've excluded passwords from the list:

The backups will run off of up to five different accounts of various types:

Account 1 – Impersonation Account

Type: local

User: autodeskvault

Password: Please see Symetri for default details

Role: This impersonation account is used by the ADMS to store data on the server, change configuration files and access the web services.  The account information is changed from within the ADMS console.  Changing this account could lock a company out of the Vault.  It is a local user account by default although this can be changed to a domain user.

Account 2 – VaultSys SQL account

Type: SQL Account

User: Vaultsys

Password: Please see Symetri for default details

Role: This account acts as the database owner inside SQL, creates the databases as required and manages the backups / restore processes 

Account 3 – SQL SA account

Type: SQL Account

User: SA

Password: Please see Symetri for default details

Role: This is the default SA account for SQL.  The ADMS uses this account to write the the SQL database.  Should these password be altered then the new password will need to be to be input within the ADMS console and altered within the backup scripts.

Account 4 – ADMS-servername (SQL Account)

Type: SQL Account

User: ADMS-servername

Password: Please see Symetri for default details

Role: All ADMS operations use this account.  Get files, check out etc...
 

Account 5 – Backup task account

Type: Local / Domain

User: Admin or service account

Password: N/A

Role: This account is used to run the windows scheduled task.  This will require enough permissions to start and stop services on the server.  It should also be a domain account if you wish to copy the backup off the server as part of your script. 

Account 6 – Vault Administrator Account

Type: Vault Account

User: Administrator

PW: blank by default

Role: This is the account that the administrator would use to log into the vault via the client.  This account is utilised within the backup scripts which will need to be altered should the details change.

Again, each of these accounts have a role in backing up the vault and users should be wary of password changes.  Common backup failures are due to passwords expiring or being changed without these changes being reflected within this backup process.

Also note that the backup will not run if the ADMS console is open on the server under any account.  Please ensure that this is closed after use.

There will be a future blog post on how to backup your vault without having the password stored/visible in the backup script so subscribe to the feed so you dont miss out.

For more information on monitoring your Vault backups please see our web pages about our ActiveEye service for Vault.  

Check out ActiveEye on our website.

Author

Chris Atherton

Managing the UK's Product Design & Lifecycle consulting service team, Chris oversees the development and implementation of detailed IT and engineering solutions for clients using Autodesk & Symetri products, outsourced solutions, or proprietary tools/techniques. Chris has a proven track record for delivering results that come from auditing businesses and management processes, working with key stakeholders, defining client needs, developing proposals and plans to meet those needs, as well as overseeing the implementation of the complete project solution.