Autodesk Vault

[#1]

*This is not a restore to a live server* Using Vault Professional 2013.

I have a test server, and I'm testing our ability to restore our live backups in the event of a disaster.  Due to the monumental size of our Vault, we use incremental backups.  On a test server I have here, I have entered the Backup & Restore area and I'm presented with a greyed out option to use Incremental Restore with a message that says this:

"You cannot restore the incremental because the server has been modified.  Detail: '25/10/12 SERVER\AutodeskVault has made an administrative change to the server: Dispatch'

I've done no such thing.  I also haven't even had the opportunity yet to point it at the backup folder, the actual backup is therefore not the problem.

In fact, following getting that message, I have deleted the Master Vault, recreated a brand spanking new one, no joy.  I then reinstalled ADMS 2013, no joy.  I'm probably next going to trash the SQL instance and rebuild that from scratch but I'd rather not have to do any of this in the event of a real recovery scenario.  Is anyone able to shed some light on what this means? 

[#2]

Hi,

'Incremental restore' option is a little confusing. It is a seldom-used feature that is probably not what you want.

It sounds like you want to do a full restore based on the incremental backup. To do this, you just need to choose 'full restore' and select the latest increment. ADMS console would locate the previous increments and original backup (located off the same root directory) - and restore them all appropriately.

Hope this helps,

Pual

[#3]

Thanks - it makes perfect sense, but it didn't work unfortunately hence why I asked this question.  

We ran a full backup on saturday, and then further incremental backups on monday, tuesday and wednesday.  I tried choosing the full restore option, picked the incremental backup from Wednesday, and it said this was not a valid backup.  I then chose the full backup from Saturday, it said this was also not a valid backup.  

I've investigated the backup log, there are no reported errors in there.  I've attached it to this post.  The full backup begain on 20/10/12 and all further incremental backups are logged as completing without issue.  I've also attached a screen print of the messaged returned when attempting to restore.

Both the full backup folder, and each incremental folder contains the typical file and folder set you'd find in a valid backup.  Databases folder, FileStores, BackupContents.xml and BackupHistory.txt.  All databases are present in the folder and the filestore folder looks fine.  

The only reason I can think of for the failure to restore is that they're located through a UNC path, but my experience has shown that this usually returns a permissions error rather than a 'not a valid backup' error.  

[#4]

After completely rebuilding the test server, putting a new SQL instance on, new installation of ADMS 2013, I'm now getting the permissions error instead of the 'not a valid backup' error.  This is because my impersonation account is a local account.

Don't you just love this, when I go to the 'settings' to change the impersonation account... the ADMS application crashes each time.  FML.

[#5]

Hi,

Given that you are also seeing this issue with a full backup, I can only assume that this is permissions related as you suggest. The validation of the backup package is just looking at simple things - like whether there is a 'databases' and 'filestores' subdirectory. It is possible that permissions are such that the files are simply not visible.

For a restore, both the SQL server service account and the ADMS user account (by default the local AutodeskVault user) need read permissions on the whole package. This is easiest if both users are domain users - but can be done by mirroring user accounts with the same passwords on the remote machine with the backup. Also remember to set permissions for both the share and the directory security.

Paul

[#6]

Hi,

What specific error are you seeing when setting the impersonation user?

Paul

[#7]

I can't even get to that bit.  I can get to the advanced settings tab, then when I click settings to launch that dialog... I get the attached, 1 then 2.  

[#8]

This is obviously something completely unrelated to the backup issue though.

*Rant notice* This always happens when working with Autodesk software, if you want to get a job done, there are always unecessary obstacles thrown at you to prevent getting it done quickly. *rant over* :-)

[#9]

HI,

I've never seen that settings error before - that is pretty strange. Do you see this on your production machine?

One option (to avoid getting side-tracked) would be to create a local user on your remote machine (with the backup) and assign it permissions. This will work as long as that user shares the same password as the one on your server machine.

Your server's impersonation user and password are in the web.config file (just search for <identity ).

Sorry you are running into these issues. Getting permissions set up can be a pain in itself  - but the settings problems shouldn't have happened.

Paul

[#10]

Randomly, I opened the global settings again, click a few of the other options in there to see if they worked or not... then tried settings again, and it worked 

So I've now changed my impersonation account to the domain administrator, but not even that has permissions to the backup!! The impersonation account on the live server is the default local user, it's only local accounts that have write access to the backup folder!! ARGH!

There's probably in the region of 2 million files in those backup folders, applying new permissions could take til the weekend to propagate down! 

Could I use the local account of the live server as the impersonation account on my test server to do the backup...? Providing that the local account on the live server has permissions to the component destinations on the test server...? This is way too much for this late in the week!