Is Archiving a Vault Necessary?

[andrewdroth]

Hey All,

Our Vault size is currently 730GB, here's a breakdown.

It apears to be growing at a rate of about 200GB a year.

So my question is, do I archive old data into a new vault, or do I bank on the cost/size of harddrives to outpace our filestore?

We are currently looking at ways to improve backup procedures, and one though was to truncate the vault. But this adds more complexity for the users when it comes to searching for files, and copying old designs.

What is considered a large Vault these days? When would you start looking at archiving old data?

[Neil_Cross]

Hi Andrew,

Firstly, much well done for being that guy who cares enough to keep an eye on this stuff.

So basically there's zero scope to archive data out of a Vault, it's just not possible, it's one of the many areas which Autodesk can and should be improving on.  But as it stands right now due to the complex potential spaghetti junction of file relationships all over the place, you can't really safely remove data in bulk and guarantee that won't screw up something you've left in the Vault.

The only options to keep tabs on this sort of thing is to reactively purge the Vault on a schedule, keeping X number of files or whatever criteria you'd like to set.  Run a SQL maintenance plan regularly, police the users so they're not throwing in unecessary files, maybe keep stuff out of there like Showcase datasets which are massive, other than that you've just got to let it grow.  

I have to admit, based on my experience I've yet to see a filestore that size have a database that small.  As reference, my current client has a filestore of 550GB and a database of 30GB.  You have a 713GB filestore and a 8.25GB database, that sounds an alarm but it could be normal depending on your usage circumstances.

Again the Vault I'm referencing has had over 150 users working actively on the Vault, daily, for 10 years, primarily Inventor data with a good few AutoCAD DWGs in there too.  

Your Vault does appear to be growing at an alarmingly fast rate though, how many users do you have in there? Have you established what the bulk of this new data is?

With regards to backups, have you implemented incremental backups? I highly recommend utilising VM tech as well for a second layer of security, snapshots and cloning is huge benefit for Vault servers.

[andrewdroth]

Thanks Neil.

Yeah, our vault is getting out of control. 

We have about 11 users, but the issue is we've started to use vault to store our Simulation files. You can see there was a sharp climb in 2013 after we started doing this.

Autodesk says Vault is compatible with Simulation. But as we've found out that is barely true. 

It seems like we're the only company doing this at the moment. 

I wish it would work as well as it does for inventor. But it looks like we may have to abondon the idea.

[swalton]

We use the FEA in inventor, not Sim Mech.  When you set up a simulation you have the option to detach the results files from the iam/ipt.  That keeps the simulation definition in the ipt/iam, and stores the results in the workspace, but does not check the results into Vault. 

This keeps those huge results files out of Vault at the cost of re-running the simulation if the results get deleted out of the user's local workspace. 

Is that an option for Sim Mech?  Is file store space more expensive than the computer time to re-run your sims?

[andrewdroth]

That's a neat idea Swalton,

I'm unaware of a feature like that in Sim Mech.

I just tried a test model and pre-results file was 45MB and post was 121MB. A pretty significant difference.

This could possible work if there were a feature to purge results after a certain time frame. The only issue I see with doing that though would be loosing all the saved presentations in the results enviroment that we use to populate our reports.

Another issue with Sim Mech is how it saves files. Instead of all the information being saved within the .fem file itself, it has an accompaning folder of the same name which hosts many files that it needs. To make matters worse, these files always have the same file names from project to project.