With Rapid Recovery 6.1.1.137 Can I back up folders, instead of entire drives?

Question

I know with Appassure only entire drives could be backed up. Has that changed? I have drives that I do not need to back up in their entirety. I am now running Rapid Recovery 6.1.1.137. I cannot find an answer for this in the knowledge base.

Tudor.Popescu · Answer

Hi chris.rodgers: 
Emte makes a good point re backup of SQL servers under heavy load. 
 
However, the msdn KB he mentions is not really helpful in your case as it only allows excluding files from VSS quescing. However, the blocks pertaining to those files that were marked as changed will continue to be subjected to back up attempts. The approach in the KB works when you create persistent VSS snapshots (without a backup application). 
 
Rapid Recovery backs up complete volumes only so, if you have specific sets of data that need to be backed up separately, you need to set them up on separate volumes. You can mount these volumes as injunction points so they are presented as folders in the Windows GUI and, as such you do not need to assign drive letters, which if enabled, may complicate excessively your setup. 
 
This approach works best on virtual machines as increasing a volume size on an as needed basis may be easier than in a physical environment.

Tim Seymour · Answer

Are you sure you don't have native SQL backup jobs or something like that occurring on these volumes that write .bak files? We see that quite often. If you have a native SQL backup job that writes a .bak file to the same disk as the database it causes huge incrementals. If that's what it is, either add a disk to the server to add them to so that they aren't being backed up or have them written to another machine that isn't being backed up. 
 
The other thing to check is SQL jobs that do things like reindexing or other data intensive jobs. Do those need to run daily? Can you have them run weekly or bi-weekly instead. I have seen a couple of SQL environments where overly aggressive SQL jobs cause more pain than solve problems with data integrity/speed of the database.

Tudor.Popescu · Answer

Hi chris.rodgers: 
 Creating junction points is not that hard and they may solve your issue. It is a simple process and I tried to document it step by step below. Basically, you attach a new drive or create a new partition on a volume by resizing current partitions and create a new one in the available space. You will use that partition to "insulate" the databases that you want to backup separately. 
 Here you go: 
 0. I have attached a new drive to a test machine. 
 1. I create an empty folder in the desired location and launch disk management (obviously you can do it from the Windows GUI) 
 
 2. Disk Management comes up 
 
 3. Initialize Disk (It is a good practice to be the same type [MBR or GPT] as the volume where you mount it)

4. Create a new Simple Volume 
 
 5. You can mount the new volume in the folder you already created now (but we will NOT do it) 
 
 As stated above, we will choose "Do not assign a drive letter or drive path"

6. Create the partition and format the volume 
 
 7. Right-click on the new volume and choose "Change Drive Letters and Paths" 
 
 8. Navigate to the folder where you want your volume mounted 
 
 9. You can now access the new volume via the folder it is mounted. At the same time it can be backed up separately. 
 
 10. The Core sees now the new volume as shown below (c:\mountme\): 
 
 11. All you have to do next is to detach the database(s) that you want backed up separately, copy both the mdf and ldf files to the new location and re-attach the database(s) in SQL Management Studio. 
 There are a few distinct advantages to separate important databases on their own volumes (I have a customer that is doing this with Exchange Databases -- on servers with 38+ volumes; the chances of losing data if something goes wrong are reduced considerably). 
 Hope that this helps.