Standing on the Shoulders of Giants: Managing Large Vault Databases

CALEB FUNK: Well, hey, thanks for joining me. My name is Caleb Funk. I'm going to be talking through the idea of managing some large vault databases.

And I chose this title-- when we're choosing titles for you, I try to get something that is a little bit different-- and this one stood out to me because a lot of the things I'm going to be talking about, so much of it is I learned from other people. So it's kind of like the Isaac Newton quote, "I'm here where I am because I'm standing on the shoulders of giants." And also, we're going to stand on some giants.

So let's take a look at this. A little bit about me-- I've been around for a while. Started working with Autodesk products back in 1995. AutoCAD 12 was my first one, so I remember digitizer tablets, and floppy disks, and everything else. Based out of Toledo, Ohio, and I've been working in Toledo with IMAGINIT for the past 22 years. And part of the reason that's relevant is because I've been working that most of that time with Vault.

So I've been implementing Vault since 2004. I have scoped and manage hundreds of Vault projects. And it's been interesting over time to see how this has changed in terms of scope and size of those different projects that we're working with, because since we're looking at this idea of large Vault databases, before we get too deep into it, I want to take a look at the learning objectives-- what we're actually going to talk about as we're going through and dealing with this.

So one of them is the idea of best practices for purging Vaults. Vaults get big because there's stuff in them. We want to figure out some good ways to take care of that.

There are some new tools. That's ones we're going to take a look at, the idea of backing up Vault databases-- not just the full Vault backup, but just the databases-- and then some alternate methods for copying the files, or moving it from one location to another.

So I mentioned the idea of the scope and size of this has changed through the years, and how Vault has changed a little bit. And this is something where I deal [LAUGHS] weekly with multiple clients talking about looking at Vault upgrades. And sometimes it's clients I've worked with for years-- this is the fifth Vault upgrade we've done for them over the last seven years, or something like that.

And this really stood out to me. It really kind of follows this idea of a bell curve and normal distribution. If you were to call me today and say, hey, I've got a Vault; we need to get it upgraded, I'm going to guess that your Vault size is about 600 gig.

I don't know why this is true, but it seems to me that it fits somewhere in there. Yeah, maybe it's 500. Maybe it's a touch more. But I'm surprised if it's something else.

Now, this follows this normal distribution rules, where we go on one end all the way up into terabyte ranges, and then, at the other end, sub-50 gig. I have a few that are very, very small. So I always tell people-- this is something I completely made up. I don't think it has any rules. But the way I think of it is, there's tiny Vaults, and then we go all the way up to the idea of a giant Vault at the other end.

Again, doesn't really affect anything. No real terminology here. But conceptually, I want us to think in those terms.

Honestly, 600 gigs seems to be some kind of average, it seems like we can handle that reasonably well with some of the standard tools that we have. It's just kind of there.

Once we start moving up that tail on either end, the long tail on either end-- excuse me, really, the long tail to the right, where we're getting up into that 1.5 terabytes-- I have a couple it's 2 terabytes, sometimes more-- these sometimes take special ideas on how we want to tackle those and what we want to do with them. And you will see growth like this over time.

So one little thing-- I am talking about single-site, no replication. It's probably the most common thing we deal with is we have clients who have a Vault. And again, this is somewhere in this range.

So just a couple of things on Vault size. When we're talking about Vault size, there's the filestore and the database. And the filestore, it's a function of the number of files that are in the Vault, how many versions you have of those files, and then the size of the files. So all of those work together-- number of files, times average file size, times average number of versions.

So this is important because you could have-- maybe you've got point clouds in there, right? 10 point clouds is always going to be bigger than 10 Inventor part files. So all of those work together when it comes to the filestore size, I do have some clients who have extremely large filestores, and it's because of the types of files that they're working with.

The database is different. Database, number of files factors into it, but it's about the number of properties associated to those files. So in that case, your database is always going to be smaller because it's just holding properties-- or at least it should be. There are some instances where we had some databases that just got out of control and were very large-- almost large as the filestore. But typically, the database is much smaller than the filestore because it's just storing those properties times however many files we have in there.

I do mention some things that don't necessarily affect Vault size. They lend to it, right? One is the age of the Vault. If you've been using Vault since 2004-- you were one of the first Vaults that I installed-- then, yeah, you've probably got a lot of files in there.

However, it doesn't always track. Again, I've got some clients who it's a storage location. They don't add much to it. It seems to be the same set of files. It grows very slowly.

Number of users can affect it, absolutely. If you've got 50 people adding things to Vault, then that's going to be-- then, if you have two, definitely can see some growth. However, it doesn't have to be. Again, the types of files probably matter more than the number of users.

And Vault Basic versus Vault Pro, I've seen some very large Vault Basics-- sometimes surprising to me how large those are set up. For the purposes of this, we're going to talk Vault Pro for almost everything. So if you do have a very large Vault Basic, you might consider Vault Pro because some of the tools we'll see, but it doesn't necessarily affect that. It's really about files, times the average file size, times the average number of versions. That's where it really comes in.

OK, so story time. And as I was putting this presentation together, I had to think of a way to structure this. And I was having some trouble until I came across the idea of telling a story.

So the story we're going to talk about is The Growth Giant and The City. So you're responsible for a city. You're responsible for defending it.

And reports have come back that out in the fields out beyond the city, there's a giant. And that giant is approaching the city. And you have to decide what to do.

Weighing your options, talking to everybody, really, you have three possible things that you can do. You can freeze, you can defend, and you can attack. So let's take a look what I mean by that as we get into each one of these.

So chapter 1, our hero does nothing. We're going to freeze. And the idea behind this when it comes to working with a Vault is doing nothing. A large Vault filestore, and a large Vault database, it's not really a big deal. It's not a concern in and of itself.

This is a call that I've had, where people call me and say, we wanted to talk to you guys today. We wanted to sit down with you and get some ideas what to do. Our Vault's getting really big.

And I tend to ask the same types of questions. Is it still working? Is it functioning as expected? Is check in, check out, searches-- everything's working the way we would expect it to?

If that's true, and the user experience is acceptable-- so people are able to retrieve files in a reasonable amount of time, it doesn't seem like it's taking forever to search for things and dig through the Vault-- just stay put. You do not have to do anything.

We do have clients-- and as I mentioned, standing on the shoulders of giants, some of the guys I talked with about internally within my company about this presentation and getting ready for this, one of them told me, he said, hey, just so you know, we've got clients with 2 terabytes of Vault that do exactly the basic backups, restores-- keep it as simple as possible.

Realistically, if there's enough disk space, there's no limit on the size of a Vault filestore or database. We can make it as big as we want to. The only limitation is disk space. And, of course, backups, having disk space for the backups. But realistically, yeah, do nothing. Just freeze. Leave it where it's at. The giant will walk on by.

However, often, we want to be able to do something. So we're going to defend. We're going to find a way where we can set this up to win. We want to be able to make sure that we're protected from some different things.

So rather than ignore the Growth Giant, we're going to build up some walls to protect our city. So for Vault admins, what this is going to mean is managing the filestore through purging old versions. And I'll walk through some of the options. If you remember, that's one of the learning objectives. We wanted to talk about best practices for that, and different things we could do, and ways we could set that up. That's what we want to approach.

The idea of SQL maintenance, SQL architecture, and then I've got an interesting one I ran into about optimizing the user experience. Remember I said, if the user experience is acceptable, then we don't have to worry about changing what we're doing with Vault. If it's working, it's working. Let's go. But there's some ways we can optimize there.

Now, as much as possible, these tasks should be automated. And there, I'll talk about some ways to do that-- typically through batch files, through script routines, different things like that. That's how we're going to begin working with automation.

So let's talk about purging old versions here. This is something this has been around a very long time. From the ADMS console, we can select a Vault to be purged, hit the Actions, and say Purge, and then select the options.

A couple of things I want to talk about within here. Whenever I thought of this, I was purging kind of like the-- I'll say the "old way." And this happens to me a lot. I've been doing it almost too long, where some of the ideas I have in my head are older ideas because that's how we used to do it.

And the way it was always done was with the version selection rules. We can say, keep every-- get rid of every version except the latest 5, 3, 2, whatever number we want there. Get rid of versions older than 180 days, 90 days, whatever we want to put there. Exclude versions that there's a comment. That's what we always did.

The thing that I would say is, pay attention to what-- I hit a checkbox there to make this light up. That's why I could fill those out. We can purge files based on revision and lifecycle rules. So it takes the revision and lifecycle rules from Vault. And built into those, if you pay attention, inside there, it shows what can be purged and what cannot.

So in that case, we don't have to make these kinds of decisions. We can simply base it off of the rules within the life cycles, and we can purge. And when it purges, it just goes.

And I really like that option. That way, it takes away that one level. We've already set up the rules, we already know what's going to get purged, and now we can set this up to run.

And again, if we just run Purge without checking any of these boxes, it just only-- it lives by the lifecycle rules. That's what it's going to adhere to. It's what's going to respond to.

So this is important. I think I've had some clients, we start talking, and we'll get into the Vault, and we'll realize there's one file that got checked in and out a lot. And we have-- there was, in one case, multiple thousands of versions of a particular file. And growth was a concern.

And I said, let's get rid of it. And very quickly, it's like, well, what if we need an older version of it? I'm like, well, you probably don't need 20,000 of these, but that's OK. But this happens, right? You'll have 50 versions of something, and somebody goes, well, I don't know which one of those I might need later,

I get it. I'm a packrat myself. I've got way too much stuff, just in case I might need it. If I play a video game, when I get to the end, I still have all my potions-- understandable. But at a corporate level, at an enterprise level, we have to make those decisions on what we're keeping. And then, the best way to do that is with the lifecycles.

One other quick thing I'll point out there is that button down at the bottom, Export Candidates. That just gives us an Excel file out of here that shows what it is going to purge. And I really like that option. I wish I knew when that showed up. I hadn't been paying attention, and all of a sudden, I realized that was there.

Export Candidates gives us an Excel file so that we can see what is going to be purged by coming up there. Now, this is all from the console. And as I said a moment ago, the way we should do this is we should automate it whenever possible.

So you can do this from the command line, OK? So this is a series of-- this is all the switches that we have where we go through and purge. We can describe the Vault that needs to be purged. We can set all the basic rules.

If you set no switches-- and this is the simplest version; it's a very easy script to write. If you set no switches, it is going to purge based off the revision and lifecycle rules, which is probably the best way to set it up, particularly if you're using Vault Professional, and you're using Lifecycles, and you have the lifecycle and revision rules in place.

That way, we're just purging versions. We're not purging any revised files. We're not purging any active files. It's just the versions.

So as it goes through, it'll connect to that, and we can purge that information out. This is a very simple script that you can create. Basically, you we can put it in as a batch file, put it to a scheduled task, and it's going to run it.

So it would be just like you would do with a Vault backup. And like we'll mention in a moment, the idea of doing it with a SQL, if we're running through and doing SQL optimization, it would be a very similar idea. So again, the idea of purging, the big rule here-- not rule-- a big idea here is purging based off revision and lifecycle rules.

Another way we can build our city walls is by determining the Vault architecture. And this is really how SQL is set up. I will say, the most common way that SQL is set up with clients that I work with is where we have it all on the same machine. ADMS is on there, SQL is installed on there-- it's great. We've got a single location. That server is dedicated to it. That's what it's there for.

SQL can be installed on a separate server. Typically-- and I'll step back-- it can be installed on a separate server. It can give performance for large databases and, I feel like probably the more important key, is large user bases. Really, we're looking at 50-plus users is where we're going to see that enhancement so that it's going to work within there.

If you have a small number of users, two or three users, you don't have to have a separate SQL server. Obviously, there's the added cost of maintaining the separate server, having that SQL set up that way, working with that. So this is optimal in certain instances, but not in every instance.

We have plenty-- I have plenty of clients, plenty of information, where I've got a lot of-- I don't want to say definitely a lot of feedback that it's working fine on a sitting on a server. We don't have to have two separate ones within there.

Once we have SQL set up-- so we've purged it, so we've got our filestore smaller, we've got SQL set up so it's managing that, we're building the city walls to keep the giant out-- another thing to do is to work on a maintenance plan and the typical maintenance plans that we have. And this is something that's been around for a very long time. I'm probably preaching to the choir for everyone here. But it's definitely something I always like to make sure people are aware of and have set up, is a maintenance plan for SQL that's going to keep database sizes small, keep log sizes small, and check for integrity.

Typically, this is set up through SQL Studio. On the Autodesk website, there's plenty of links on how to do that and where that information is. A lot of times, we-- "we" being [INAUDIBLE]-- will script this.

We'll set this up as a script that kicks off. Again, it's a scheduled task that goes through and runs the SQL maintenance plan so that we have everything done automatically. And it's going to do the same things.

The big thing is those log files-- those can take up so much space for that-- and then generally working with the databases. So we keep them fairly small. So that can be definitely something to consider. We want to have that scripted. We want to have that in place.

So everything that I've been talking about is very much admin-based, right? We're going in from the admin side of things. We're setting up these different pieces that we have in there.

This one's kind of interesting. I came across this very recently. And I said, this one's for the users, right? So at the user level, this is something you can do.

And the example I'll give is I had a client, and they had thousands of files in a single folder. And it was just how they had set things up before and they were setting it up now. And if they clicked on that folder in Vault, it would take a while for that to come up.

I mean, it was still calculated in seconds, but it was getting close to the 60 mark, right? It was they couldn't just click on it and see the information. And as they added files, it took longer and longer and longer.

So we talked to them about splitting this up, putting it in different areas. We did different searches so that they could search on things easily and find it, and didn't have to work through, deal with all these files in a single folder. They could search for specific things.

And that helped, right? You can set the page size so that we're only seeing 200 files at once. That helps as well. So there's definitely options we have there.

But here's why. I found out why. I never knew why, and this was very exciting to me.

So most properties that we have that appear on a Vault file-- so the lifecycle state, the revision, file name, all of that-- those are held in the database. Those are held in SQL. So if I click on that folder, they should display very quickly.

There are runtime-calculated properties. These are typically ones that check what is on your disk compared to what is in your Vault. So they can only be calculated when you click on that folder. They're not maintained. They're not kept.

So if you have thousands of files in a folder, and you click on it, it's checking those thousands of files to see what's on the disk, to see if there's any difference, and then, basically, slowing down what we have when we get back from that. And removing those particular properties from the view can improve low performance.

Now, best practice, no more than 2,000 files in a Vault folder, right? That's really how we want to set that up. We don't want to-- this isn't, hey, just throw everything in one because we can turn these off.

But if this is something you're running into, this is a way that we can combat this idea of dealing with a really big Vault. How do we get this to improve? So interestingly enough, I have found no list of these properties anywhere. I thought, well, great, runtime calculated properties. Let's go grab them, and I'll turn them all off.

Could not find it. However, I did get some information from Autodesk that if they cannot be found in the Advanced Search Tool, then they are runtime calculated. So I took a look at what's in the default view, and there's three-- Vault status, the Entity icon-- whether it's an assembly, a part, a PDF-- and the Vault status modifier.

So that's what it's looking for to calculate those. If you turn those off, it's only looking at database-level information and not at runtime calculated. So maybe you want those. I understand; I'm not saying you have to turn this off. I'm saying this is another option that we have to clean that up so that users can work through that, see that information, and view it more easily.

One thing I would think to do that may be worthwhile is have a separate view. Call it a simplified view, or a quick view, or whatever you want to call it, but we can create custom views within Vault and have those turned off in that view. That way, every time we went to a folder, that view is applied, and I can turn back on the full one if I wanted to. But just super interesting idea that I had no idea these things existed, but that's exactly how they work within there.

OK, so we can freeze, let the giant pass on by. We can build up our walls by having these different tools in place, where we've got correct database structure, where we've purged it out so we've got fewer files, everything is running properly. But sometimes, you've got to fight. So we're going to talk about how we can wrestle this and work with it.

And where this really comes in is typically in the idea of migrations-- whether it's migration to another version, or whether it's a migration to another server. In each case, it's the same steps. And preferably, we are going to a new server when we migrate versions for working with us.

So a couple of things about this. The little note that I have there is directly from Autodesk Help. They say they don't support third-party software methods to back this up.

So we're kind of in an interesting area here. These are tools that exist within the Autodesk tool, so it's not something I'm just making up here or working through. But we want to-- I just want to say, this is definitely something-- and I'll mention this again-- we would want to test it. We're going to definitely want a standard Vault backup before you go. But I do want to talk about some of these different tools that we have within here.

So this was added with Vault 2024, and it's really interesting, the option that we have in here as part of this. It's to back up the databases only. So it's part of the Backup and Restore Wizard. It's just a checkbox that we have in there. And when we do this, it's going to only worry about the databases. No filestore goes along with it.

We also have an option for restoring that we can-- and this is new for 2024 as well, to restore-- and we can use an existing filestore that's there. So effectively, we can decouple the idea of the filestore from working with the databases. Why?

It's interesting, and I thought it was also interesting that when I was looking at this, the backup and restore options give no indication why. It's just there. We can do it, and we can run through and do that.

So real quick, I'm just going to jump over to my ADMS, and I'm going to pop this up, and I'm going to run that backup, all right? So I've got my Vault set up here. Yep, sure is. And I'll go through here, and I'm going to do a backup.

So when I do the backup, and when I go through here, I have the option of backing up the databases. So I'm definitely not going to worry about that. I'll just drop this out here on my drive in my databases only folder that I've set up. And I'm going to say, let's back up the databases.

And it says, hey, selecting this option may cause an incomplete backup with no physical files. OK, that does not seem like a good option. But I'm going to say OK, and I'm going to finish.

What I'll point out here is how quickly this backup runs. Mine are very, very small databases, just for purposes of time and working through here. But all it's worried about copying out is the database information that's there.

When I go to restore-- and I'm going to do the same idea when I come in here and do a restore-- I can go select those databases. Oh, and by the way, I'll just show this real quickly. Once I get into here and take a look at that, it is very empty.

I mean, it is just the databases, like we would expect, right? We're just seeing just that information. It is the knowledge master and the two vaults that I had there. That's what it pulls.

So once I'm over to here, I can use that. And all I'm looking at is those databases, so I have no filestore to restore. But I do have the option of saying, use existing filestores. So it's won't pull in the filestore that's there. It's just going to point to an existing one that I have in place.

And that's where we're going to go to point 2. I'm actually not going to finish this out. I'm just going to jump here real quick into the idea, back into my presentation, so we can talk through this a little bit and where this is at.

So this is a different idea. We're decoupling the database from the filestore so that we can wrestle this into submission. And the filestore still needs to be there. And typically, what we've used in the past is Robocopy.

So this is robust copy. It's a standard Windows tool. You run it from the Windows Command Line. So you bring up CMD, right? You just bring up your Windows Command Line, and there's only three switches. It's pretty straightforward-- or actually, maybe more. There's only three switches I've ever used.

A source, a destination, and then the /mir, mirror. That is going to mirror the directory tree. So I can effectively say, copy from my filestore A here to filestore B on the new server where it's going to go. Go ahead and copy that over. And it's going to run in the background.

This copy is very fast, and that MIR will skip files that already exist. So I could copy it, and if someone added a file, I could copy it again later. And it's not going to copy the whole thing. It's only going to copy the delta-- what has changed since the last time, what's the difference between the two.

So this is significant. This makes life a little bit easier. And this is a method we have been using and I've been using in a couple of different instances where I had very large Vault file stores, and I needed to move that information to another location.

And the concern was, well, gosh, Vault takes two days to back up as it is. We're talking 2 terabytes of data. We then have to take that backup, copy it to something else, and then restore it. We're just extending time out here.

So the idea here is we can take Robocopy, use it to copy the information-- while people are still working, I can copy the whole filestore-- then there will be a moment when I'm going to say, all right, everybody's done. Let's copy whatever's changed and then go from there.

So this is the warning that I'm going to give you. I mentioned this was coming up, but I want to talk about this a little bit. This method absolutely works. I've used it in a couple of different instances.

This is a great paraphrase that I wanted to use because this is-- we're getting in a slightly different area here. So what I want to do is talk about some of the best practices for doing these large-scale type of copies and working with this information. Always test the process before you get into the point where we're taking this information, and we're going to copy it over, and we're going to begin to use it, run it on a test server, right? Because we need to know this work the way that we'd expect it to.

Prove the workflow-- so that's the other piece of that test process. I'm giving you the concepts, and I'll show you an outline here in a moment of how this is going to go through and what that's going to look like, but you need to prove it in your own environment, right? This isn't something you're going to run back and say, hey, this looks great. Let's just copy just the databases, and throw this over here, and away we go.

And then, you need to understand how long the process takes overall. To me, that's part of the reason of doing this, is so that we can come back to the engineering team and say, Vault's going to be down for a day, two days. There's going to be this period of time when we're copying over to the new server, when we're switching over to it, that you're not going to have access to this. And let's plan that out.

So always test the process. Run this on a test server. Prove it out. Understand how long it's going to take.

With all that true, and with all that in place, let's take a look at what a sample migration might look like. So what you would do is Robocopy the filestore. This, users can still use Vault while it occurs. This allows you to pre-stage it.

So I'm going to take-- I'm going to use Robocopy, copy from server A to server B. Maybe it takes a day. Maybe it takes two days, because terabytes of data, and it's running. It all depends on what servers you have, and where you're at, and what's going on.

But the idea is, we can get that information over there while the Vault is still running, while people are still in it. We can do that as a separate function from the backup that we're about to take. And to me, that's where this really comes in.

Instead of saying, hey Vault goes down on Monday. We're going to run a backup, copy it over, and then put it back up-- the staging of this is going to help. OK, so now we've done that, Robocopied the filestore. We've moved it from one side to the other. The next step is, once that database-- now, we would run, we'd back up the databases.

That's that new function I just showed a moment ago that has the option says, hey, I'm not taking a filestore. I'm only taking the databases. Once that has run, those databases get copied.

So this is the line once. We start running that backup, just like we would run a normal backup, once we say, hey, we're going to back up the databases, this is the cut-off. From here on in, hang on till we get this back in.

So we copy the databases over. We Robocopy again. It's going to copy the files that have been added or changed since the last Robocopy.

So it's using that switch. It's going to copy the information over. Now, I should have an identical filestore and my databases copied over to that. That means I can use that restore option where I restore the databases, and I can say use existing filestores.

Here they are. I've already copied this over. This is what they look like. All of the normal things take place-- normal database migration, validation, everything we would expect to happen for a Vault migration. That's what occurs at that point.

This method-- we called it the "alternate snapshot method" internally-- this something we've used for a while. And it was a little harder before Autodesk added these great tools into here because we could copy the databases, but we had to do it via SQL. And then we could take that, and the restore was a little tough because you had to attach the databases. And it would mess up users, and we had to fix that.

But we this has been done for a while-- I'll say years. I'd have to think about it a little bit. But for very, very large Vaults, we've used this method for years. The difference here is it's become a little simpler using Autodesk-specific tools, doing this through the Vault.

The only thing that isn't Autodesk-specific is that Robocopy-- copying the filestore over there. Everything else is just part of the functionality that we have within Vault. So it's made life a lot easier when it comes to working with that.

So this seems like a lot, and it kind of is. So why? Would we do something like this?

Well, the big thing is this reduces downtime. And I see this particularly if we're copying to the cloud. If I'm moving from, I've got a large Vault database and filestore, and we say, great, we want to begin using an Amazon Web Server, and that's 2 terabytes of data we've got to copy up there. I had one client who was definitely moving to the cloud, and at one point then said, nope, I'm not. That's not going to work. It's going to take too long to copy this up there. Their upload was the connection wasn't great, it was going to take a very, very long time, and the determination was made, we're not doing that.

So that was a if we're doing this again we can stage it all we have to worry about is the databases and we can really reduce the downtime. Realistically, a large Vault-- and I'm talking those giant ones, you know, terabyte, 1.5, 2 terabytes or larger-- those giant ones may take days to create a backup-- literal days, you know, 72 hours, whatever it may be. And if we're staging it that way, that has to happen, then that backup has to be copied, then it has to be restored.

So this is just a standard move that we have, which, again, is probably the best in most cases in these instances for very, very large vaults. It just takes so long. It definitely works. It works great. It's just the length of time that we're looking at.

So this method that we have allows you to separate the copying of the filestore and databases. We can disconnect those and then reconnect them. But it's all using tools that are built-in there.

Again, we've done it before, but it's been a little bit-- it's just been a little bit outside. It was a very interesting thought that had been approached. It's a very different approach that we'd come up with to begin working with that. I love how this is built into it. It's all here so we can get in and begin using this.

So what we were talking about-- ramping up this idea of going through this little session. One thing I wanted to talk about with the learning objective is reviewing those best practices. Again, really focusing on the idea of, Purge is a really simple tool if we have already set up the rules for the life cycles and the revisions. It's much easier to work with.

There's that idea of the benefits of understanding-- so we got that one, -- understanding the benefits of backing up the Vault databases. Because again, on its surface, it doesn't appear to do any-- it's like, I'll do this, but you don't get the filestore. Well, the reason is we can disconnect those from each other, and then we can move that across with using much less time to do it.

It's a much smaller move. It's much less information that we have to move much less data. So that's why we would back up just the databases. We will always need the filestore. We can't reconstruct the filestore just from the databases, but we can disconnect them so that we can back them up separately.

And then, I talked about alternate methods for copying the filestore. Robocopy, realistically, I could just use my standard Windows Copy, take that, drag it across. I would not suggest it. Robocopy is much more effective, and it has a lot more options, particularly that mirror-- the fact that it's going to grab files that have changed, and it's going to grab files that are new. So pull that information across. That way, we've got that within there. So we talked through that.

So a couple of final thoughts, just kind of wrapping up the idea of this within here. Which one of these should you choose? We talked about three different things we could do. I will say the same thing that my grandpa always said when presented with more than one type of pie-- I'll just have a little of each. OK?

So first of all, yeah, do nothing is there, and it's a pretty good option. A properly configured Vault with enough RAM and enough disk space-- very little adjustment. If it's set there, don't worry about it. You don't have to do anything.

But properly configured is important, so build your city walls. Make sure those extraneous files are being purged. Use best practices on the folders, right?

No more than 2,000 files. If you have to, adjust the properties to optimize the experience. Make sure SQL is being taken care of. So have your defenses strong. And when necessary, we can wrestle the growth giant. We can use those tools to migrate those large file stores and databases with as little impact on downtime as possible.

Hope you enjoyed this whole little tour through what we have here, got some new ideas-- whether it's changing the way you're viewing your files and seeing that information, or whether it's working with the idea of switching out, disconnecting those databases, and making different copies. Hope AU was great for you. Thanks for listening.