Well, it’s been way too long since I updated this one. Time for a bit of how-to!

There are times when ‘normal’ backup procedures are in doubt, or even when there are no backup procedures whatsoever. During these times, it’s pretty much essential to either create a good backup/reco scheme or well simply get your images on a off-server drive in case something happens WHILE you’re getting your new strategy in place.

To get to your images, you’ll first have to get access to the server. USUALLY ESX servers are given an SFTP setting, which only certain clients can handle. In this case, I’ll be giving examples as though someone was using WinSCP as their SFTP client. Not all ESX servers will require this, so test logging in with a normal client when in doubt, if it doesn’t work, well then you know that you’ve got either a config problem or need an SFTP client.

I’m not going to cover how to config the client, it’s pretty straightforward and if you’re playing with ESX you should know what you’re doing. If you don’t know what you’re doing, stop now before you destroy something and go get someone on your IT team that knows what’s going on. I cannot stress this enough for you can do irrevocable damage to your system, and I’m not responsible for anything that happens regardless.

If you are comfortable with what you’re about to do, then go ahead and read the rest of this post… otherwise, just rely on someone that does know, or get a true-blue backup solution. Don’t risk your company’s data over a gamble, it is never, ever worth it.

When you log in to your sever with WinSCP, you’ll (of course) end up seeing your directory tree on the left, with your viewing pane on the right. Navigate up to /, and you’ll see a directory called VMFS. You’ll find all your settings for your depots in there, in my case, there were two directories with long hash-style names, and two others with the names of our assigned datastores. If you click on the datastore-named directories, you’ll see that they are actually shortcuts and will auto forward you to the relevant directory that contains the images assigned to that datastore (which are contained in the long-style hash-named directories).

You’ll pretty much find everything you need right in there.

In the main folder of that hash-directory you’ll find a handfull of .sf files (.sbc.sf, .vh.sf, et al). These are journal files used for filesystem checks and crash reco.

You’ll see a separate subdirectory for each image and template you possess. This is the core of your work, and more or less your baby. If your production time can afford it, shut down your VMS and then set off to copying them. In my case, I used a 500gb WD eBook external for this particular operation. Of course, this may not be sufficient for some larger VMs (like core Dbs that could be terabytes big, we have one of those on a separate VM), and there could be better solutions available to you there, but this was mine!

Once your VMs are powered down, it’s a matter of drag and dropping the directories to initiate a file transfer to whatever location you want to put them in. Fair warning, this can take a VERY VERY long time depending on what kind of size and transfer set up you have!  If for some reason you got a ‘cannot copy’ or ‘permission denied’ error, then one of two things is happening; either you still have the VM powered on, or the user you logged in as does not have the correct privs to allow copying of files in that directory.  You may want to log in as root to do this, if your sftp setup is configured to allow root logins.

Now, once it’s all done, there you have it, you have your images off-server. Since we wouldn’t want you migrating images without a VCC license, I won’t be covering how to transfer them to another unit… this time! ;)

You Should Also Check Out This Post:

More Active Posts: