Hello -
We are currently using the BackupExec Quick Start edition that came with our Dell PV124-T tape drive, which has been working well for about 2 years now, however I think we've finally grown out of it's functionality.
To understand where we want to go with BackupExec, I think it's probably relevant to understand what we're currently doing with Quick Start edition. The majority of the data we back up is SQL Server 2008 native compressed backups, and SQL Server 2008 Analysis Services native compressed backups. We use the following process to get these backups onto tape using BE2010.
Current Process
We use a pretty standard backup policy were each SQL Server takes Monthly Fulls, Weekly Fulls, and Daily Diffs. Each SQL Server is responsible for taking it's own backups and writing them to a backup dump folder on local disk. We then have a job that runs from the backup server that "moves" the contents of the backup dump folders to a local backup staging volume each night. The local backup staging volume is then written to tape on a weekly basis.
I understand this process isn't flawless, but it works pretty well considering the very low probably of a SQL Server failure at the same time a failure of the backup staging volume. Even if that worst case scenario, we are always less than 6 days from a full tape backup of the backup staging volume.
Here's a quick visual example of the progression of a backup from live DB to tape:
(Live DB on SQLServer01) -> (Local Backup on SQLServer01) ---> (Moved to staging via UNC) -------
ExampleDB01 --------> E:\Backup\ExampleDB01_050112.bak -> \\SQLServer01\Backup\ExampleDB01_050112.bak
---> (Staging volume on backup server) --------> (D:\BackupStaging Full backup to LTO-4 tape)
---> D:\BackupStaging\Weekly\ExampleDB01_050112.bak -> E:\BackupStaging\*.*
This method worked fine for serveral years with the capacity of our staging volume and the speed of the LTO-4 backups easily scaling up to 6TB. Now that we're cresting 6TB/week though, this model isn't working so well anymore. We are currently keeping hte following on the staging volume:
- 2 Monthly Fulls
- 3 Weekly Fulls
- 6 Daily Diffs
Which provides 1,2,3,4,5,6,7,14,21,30, and 60 day restore points (which were the original requirements for the backup policy). We've considered making the weekly files Diffs based off the Monthly, but that's risky and adds another layer of complexity
New Proposed Process (and questions about Data Deduping in BE2010)
With backup staging space running low, and more databases being created in both Pre-Production & Production, we need to modify our strategy. One strategy is to simply buy more staging storage, but this isn't optimal as our tape backup job would then run for nearly two days and cause tape-swapping headaches in our DC.
So in my latest research, I found the "Data Deduping" option you can purchase for BackupExec. My questions to the forum is this -
Question - To really take advantage of the data-deduping, I really need to have BE2010 pull the backups straight from the UNC paths on each SQL Server, correct? Otherwise, I'm only saving space on what's finally written to tape, and I would actually end up comsuming MORE disk space on the staging server as it would have both the full un-deduped folder as well as the deduped folder on the local volume.
Is that possible to have BE2010 dedup from UNC paths to a local folder? So for example, could I have deduping configued as follows (all folders on the right are local folders on the backup staging volume):
\\PRODDB01\Backup (dedups to) ----> D:\Backup\PRODDB01
\\PRODDB02\Backup (dedups to) ----> D:\Backup\PRODDB02
\\DEVDB01\Backup (dedups to) ------> D:\Backup\DEVDB01
\\DEVDB02\Backup (dedups to) ------> D:\Backup\DEVDB02
etc, etc, etc up to say 10 Production Servers, and 5 pre-production servers
I'm assuming this would mean that the data in D:\Backup\*.* would only be the *deduped* data, which I could then point a tape backup job to rip the D:\Backup\*.* folder to tape.
Is that possible? Are there any limitations, e.g. deduping doesn't work with UNC paths?
Thanks,
- Jeff
