Who actually manages Vault? Roles, backups and routines

An engineer wants to pull up an old version of an assembly because the customer is walking back a change. Easy job with Vault, he thinks. Until it turns out the backup job has been failing quietly for six weeks, that the error notifications go to the mailbox of a colleague who left, and that nobody knows exactly who is supposed to be watching the server. Vault always just worked, right?

You see this pattern at many machine builders and sheet metal shops: the environment gets set up neatly by an Autodesk partner, then runs for years without trouble, and precisely because of that reliability the sense of ownership evaporates. In this article we make Vault administration concrete: which role to assign, which weekly, monthly and yearly routines belong to it, how many hours that realistically takes and what is better outsourced. Backups get the lead role, because that is where the damage is biggest when things go wrong.

To mark the boundary: this piece is about managing the environment, not about the daily discipline of checking in and working tidily; that is a story of its own. If you are still wondering whether Vault fits your team size at all, first read our honest answer for smaller teams. And if you use a toolbox like Thundercad next to Vault, there is nothing extra to manage on this front: it runs on the workstation, while the maintenance below belongs to the server.

Why Vault needs an owner

Vault is server software: a SQL database holding the metadata, a file store holding the files and a job server for background tasks. That is a fundamentally different category from a program on a workstation. If Inventor crashes, the engineer notices immediately and it is fixed the same day. If a backup job fails, nobody notices anything. The environment keeps working while the safety net underneath it has disappeared.

So the dangerous thing about Vault is not that it is unreliable, but precisely that it is so reliable. The signals that ask for attention are all there: a disk filling up, a queue of failed jobs, an account list full of departed colleagues, an error mail from the backup. Without an owner, those signals land nowhere. An owner is not a luxury but the cheapest insurance there is: someone who reads the notifications and spends five minutes a week confirming everything still checks out.

The role: four responsibilities, one name

Vault administration is not a job title but a role, perfectly combinable with engineering, work preparation or IT. The core consists of four responsibilities:

• Backups and recovery: a consistent backup of database and file store runs, the log gets read, and restoring is genuinely tested from time to time.
• Accounts and permissions: new colleagues get the right profile, departed colleagues are removed, and permissions keep matching how the department actually works.
• Updates and versions: the annual update is planned in good time, together with the Autodesk partner and in step with the rest of the environment.
• Server health: disk space, database growth and the job server queue get looked at before they become a problem.

Assign the role to one person by name, plus a substitute for holidays and illness. In practice a duo works well: someone from the engineering side for the functional part, such as permissions and categories, and IT or the partner for the technical part. The pitfall is shared ownership without a name: then everyone reads the error mail assuming somebody else will look into it.

The administrator is also the natural point of contact for tooling that connects to Vault. If the team publishes drawing packages with Batch Publish, which exports drawings in bulk to PDF, DWG, DXF and STEP and works together with Vault, you want one person who understands how the two sides touch when something jams.

Backups: made is not the same as tested

A Vault backup consists of two parts that belong together: the database and the file store. Copy only the files and the history is worthless; secure only the database and you have metadata without content. So use Vault's own backup facility or the script your partner set up, and have the result written to a different machine or location than the server itself. A backup on the disk that crashes is not a backup.

Then the real work starts: verifying. Read the log weekly, or better still, have the outcome mailed automatically to a shared mailbox, so the notification does not move away with a person. And schedule a test restore every quarter: put the backup back on a separate machine, open a recent project and check that the latest versions are there. Only then do you know the safety net works. When companies do this for the first time, something turns up remarkably often: a file store sitting just outside the backup set, a job that has been stranding on a full disk for months, or a copy neatly written to the same physical disk as the source.

The rhythm: what happens weekly, monthly and yearly

Administration is light when it is a rhythm and heavy when it is incidents. The schedule below is a starting point; the times are assumptions for an environment with five to fifteen engineers.

Added up, that is two to four hours per month of fixed routine, with two peaks a year around the update and the cleanup. That is manageable, and it is out of all proportion to what a single failed recovery attempt costs in downtime and reconstruction work.

If the administration has slipped for years, do not start with a schedule but with a catch-up. How to clear the backlog in one go, from clogged queues to a forest of stale permissions, is covered in The Vault cleanup day: clearing a backlog of maintenance in one day.

What you outsource to your Autodesk partner, and what you do not

A good partner is to Vault what a maintenance contract is to a machining centre: you buy in knowledge and reserve capacity you do not need every day. Sensible to outsource:

• the annual version update and the database migration that comes with it;
• a move to a new server or a change in the infrastructure;
• recovery after a crash or persistent database trouble;
• the initial setup of lifecycles, categories and permission profiles.

What you cannot outsource is responsibility. The partner sets up the backup; whether it still runs is yours to check. The partner advises a permission model; who gets which profile is your call. So agree on two things: who calls whom when something breaks, and which checks the company keeps doing itself. Put that on a single sheet and attach it to the role, not to a person. That way the administration survives a staff change too.

Frequently asked questions

How much time does Vault administration take per month?

As an assumption, count on two to four hours per month of fixed routine for an environment with five to fifteen engineers, plus two peaks a year for the update and the major cleanup. It is a role next to an existing job, not a separate position. Whoever keeps the rhythm spends less time overall than whoever has to reconstruct every six months how the environment is doing.

Who makes the best Vault administrator: an engineer or someone from IT?

A duo with one name carrying final responsibility works best. The engineer or CAD lead takes the functional part: permissions, categories and the question of what a sensible setup looks like. IT or the Autodesk partner takes the technical part: server, database and backup infrastructure. Do make sure the functional owner can check the backup status personally; that is the one task you never hand over completely.

What is the absolute minimum if we have little time for this?

Three things: a weekly glance at the backup log, a quarterly test restore on a separate machine and a monthly check of accounts and disk space. Together that is less than two hours a month and it covers the most expensive risks. If you also want to shrink the routine work around publishing and exporting, you can try Thundercad free for a month.