This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

 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.

  • What are best practices for backing up SQL server volumes?
    Because so much data changes daily on our SQL servers, our incremental backup are becoming unmanageable. Since I cannot backup individual folders, how do I keep these backups in check?
  • How are they becoming unmanageable? Its hard to give advise without know the exact pain point.

    As a general rule, we tend to have very different retention setup for SQL servers vs other servers. We often run backups with a shorter duration (every 15 minutes) and keep every recovery point for 3 days. But after that, our retention drops significantly. we typically only keep a few recovery points that are older than 3 days. If you have to restore a SQL DB from an image that is 1 month old, you have serious problems.

    As far as excludes/ includes. I am not aware of any way to do this with Rapid Recovery and I agree it is an annoyance as every other VSS backup I have seen can do this. But if you are interested, you maybe able to do this from VSS but I have not used this and it looks like it maybe a mess to setup and manage

    msdn.microsoft.com/.../aa819132(v=vs.85).aspx
  • Rapid Recovery and AppAssure both back up the full volume. There is no way to exclude files or folders from backup.
  • 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.
  • We have DB servers with bases of almost 1TB. I routinely have incremental backups of at least 700GB, because so much data is being changed on a daily basis. Because the way the servers are set up and I can only back up entire drives, and not just folders, I am backing more than I need to. Plus these servers get replicated. That is what is causing the problems. If I ever have to rebase a 2TB server, it takes 4 days to replicate it. Plus I am running out of storage space.
    We are in the process of moving our datacenter and I have to come up with at least of 10 TB of space. I am looking for ways to do that.
  • Short of re-engineering our entire network, that doesn't help me a whole lot. That is also a little above my level of expertise.
  • The issue with replication of multiple bases images exists because of what I believe to be several massive issues with Appassure/ Rapid Recovery but Dell/ quest does not agree.

    The "solution" to your issue is to increase the dedup cache. This is of course is a terribly documented and impended "fix" by Dell to work around these bugs. We had a great write up on this that us users created but it looks like dell/ quests has deleted it even though they swore no information would be lost during the move to a new forum.
  • Seems like sometimes I walk by the server room and sneeze and those servers re-base
  • 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.
  • Right now I am re-replicating 2 servers because of multiple bases. 1=2TB, 1=1.45TB. Both been running since last Friday