Recently I contributed on the DataGravity corporate blog about things that make an IT Admin's life easier. Often it is the simplest of things that make the most impact in solving our IT pains and the pains of our customer base. For example, how many times have we tried to find something that we are looking for, but to no avail? How many times have we been asked to help somebody find what they are looking for? It is bad enough when we often can't find our own belongings, but when trying to find somebody else's, it can be even more difficult. As IT administrators, we will be inevitably be tasked with helping our customers, users, family, and friends with helping them find something on their computer. In a world of right clicks, moves, clouds, syncs and copies it is pretty easy to think you are putting files in one place but when you go to find them again - they are simply not there.
Let's look at the most basic example: a simple move of a folder or file from one place to another on a shared department drive. This might be done by mistake or on purpose, but can have all kinds of repercussions. If the department drive sits in a law firm and contains case data which is separated by case number in folders, the move might have major repercussions being in the wrong working directory. If that share contains folders and files that make up a marketing campaign and there are several team members working all on the same campaign, their links and shortcuts to these files are inevitably broken by the move. I am sure you can fill in your own examples, but it is clear to see that a simple copy/paste/move mistake may consume a lot of time to sort things out. Unfortunately even in our world of IT sophistication there are no clear set of easy to use tools to help recover from this type of mistake.
In this post we will highlight 3 simple steps that you can take using DataGravity's search and data-awareness to quickly identify copies and moves of folders and files. The DataGravity Discovery Series will assist us with identifying all files and/or folders that were moved, when they were moved, and who performed the move. We will utilize it's historical view capabilities to determine where the data previously resided so that we can be assured that we are moving it back the correct location. So let's look at the scenario.
Scenario:
Our favorite user, Gabe - calls in to report that he can't find the file he is looking for and thinks he may have moved them to the wrong place. Gabe works in IT and saves his files on the department share drive. His share drive is mapped to the IT department share. Gabe can't remember what folder the file actually lived in or where he might have moved them, but he is pretty sure that he always saves them to his share drive. He forgets the name of the file he was working with, but does remember that it was a PDF.
So we are being asked to find a single PDF file that Gabe has 'misplaced' somewhere on the IT department share - we think. Needless to say we don't have to much to go on here, but let's see if we can get to the bottom of this using a couple of simple steps within the DataGravity UI.
WHERE DID THE DATA GO?
Step #1: Finding the Missing Files and Scoping the Activity Performed
The first step is to see if we can find the information that moved - hopefully we can narrow this down to something more specific then 'a PDF file'. There are several ways we could approach this using the DataGravity UI and the most obvious might be using the full search functionality built into the array. But in this case, we are going to take a little bit different approach. In fact if I know any of the following pieces of information: File Name, Person Calling whose Files Moved, Share Name, Timing when the Move occurred - I can utilize the built in auditing capabilities of the DataGravity Discovery Series to filter out only those items that were moved. I am going to start by looking at the IT department share and view all activities that have ever been performed on that share. Using the filtering techniques available to me, I can simply filter in on any key operatives typically associated with a file or folder move, namely: delete (removing the file from it's original location) and write (writing to a new folder location).
When performing this activity filter (1) on the IT Department Share (2), we can quickly find a PDF file (3), that is associated with our caller Gabe (4), and I can confirm when the move occurred (5). At this point we can determine if it is the vsphere-esxi-vcenter-server-55-installation-setup-guide.pdf file that Gabe was calling referring to. He of course says 'that rings a bell.'
STEP #2: FINDING Where the files were Moved - Different SHare
Now that we know the name of the file that was moved, who performed the move, and when it occurred - we have to figure out where it was moved to. Luckily it is just as easy to filter on operatives indicative of a file move on any department share. This time we will modify the filter to check for: create (saving the file to a new location), write (writing the file) and set ACL (making sure the permissions are correct after the file is moved to the new folder structure).
We can then quickly see a pattern that matches our filter (1) on the Marketing share (2), with the same file name (3), user (4) and data/time stamp (5). In this case we can definitively tell our friend Gabe that he moved the PDF in question from the /VMware/VMware_Docs/VSphere/5.5/docs folder on the IT Share to the /Presentations folder on the Marketing share. At this point we can move the file back to it's original location, or have Gabe perform an in place restore (steps for this in a different post, but very cool, and very powerful).
STEP #3: FINDING WHERE THE FILES WERE MOVED - Same Share
Let's take a look a small twist in our scenario. What if these files were moved to the same share and not between shares. How would this be any different, if at all? In fact there is a slight difference in the operatives that are performed when a file is moved within a share vs. when a file is moved between shares. In fact we would take the same approach, following Step #1 to find the file name in question, when it was moved, and who moved it.
Rather then the delete operative that is used when files move between shares, the operative here is rename since it is simply relocated on the same share and not deleted from it. Looking at the details of the file in question we can see the rename operative, who it was performed by, and when it occurred.
Using this detailed information we can call upon the historical timeline of the file to see exactly where it was moved from and moved to. We step into this historical timeline and filter by the file name by accessing the Discovery Series Trending feature.
We can search for many things historically, but in this scenario we will search for the file name.
The results show that the file vsphere-esxi-vcenter-server-55-installation-setup-guide.pdf (1) was moved within the IT share (2) from the /VMware/VMware_Docs/VSphere/5.5/docs/ folder to the /VMware/VMware_Docs/VSphere/5.5/ folder.
REcap
There you have it. Despite a very limited amount of information provided by Gabe, it only took 3 simple steps to identify the file and folder moves he performed and the detail required get that data back to it's correct location.