07-13-2020 01:27 PM - edited 07-13-2020 02:38 PM
I would like recommendations for increasing the speed of file system backups of Windows file servers running Windows 2012 and newer which are using Windows deduplicated volumes. Currently, we have many file servers ranging in size from a few TBs to 12+ TBs.
We are using several options to try to speed up the backups:
The main problem is the Shadow Copy Components portion of the client backups which can take multiple days to complete and is limited to one stream.
I often see messages like these:
Jul 12, 2020 12:01:35 PM - Info bpbkar (pid=6616) not using change journal data for <Shadow Copy Components:\>: not supported for non-local volumes / file systems |
Jul 12, 2020 12:40:16 PM - Info bpbkar (pid=6616) not using change journal data for <Shadow Copy Components:\>: forcing rescan, each file will be read in order to validate checksums |
07-13-2020 02:19 PM
1. Are you using DFSR? There are special configurations needed to efficiently back up DFSR servers.
2. There is an option in the policy Attributes tab called "Enable optimized backup of Windows deduplicated volumes'. You'll want to ensure that's checked.
3. Why do you have client-side deduplication enabled? Are the servers located outside of your data center/in remote locations?
4. How many drives are mapped to these file servers? How often is the data on the servers changing? Are any of the drives mapped over the network?
5. If you're using Accelerator, you need to make sure you're running Accelerator Forced Rescan backups semi-regularly (I recommend using your Monthly backups for this, but it can be 3-6 months if you're not having any issues).
07-13-2020 02:34 PM
Thank you for the response.
07-13-2020 08:09 PM
07-14-2020 07:16 AM
On the forced rescan message, there's a bug in NetBackup 8.1.1, where the archive bit doesn't get cleared on the backed up files. This may cause Accelerator backups to behave like full backups. Ask for EEB 3989637. Or upgrade to 8.1.2.
We also have an 8.1.1 EEB in verification regarding DFSR performance. You can check out EEB 4003077 to see if it will help you. Version 2 of 4003077 includes 3989637.
07-14-2020 04:46 PM
07-15-2020 05:27 AM
@richardw2 how many active streams (backup jobs reading data from your file servers) do you keep on the client? I would suggest 3-4 active streams per client, this will help boost completing the backup job sooner with better overall performance.
07-15-2020 09:57 AM
The policies allow for multiple streams. Since the primary concern here is regarding DFSR servers with deduplicated volumes, that is the focus. The backup streams for the non-DFSR data (up to around 4 streams - 1 per drive) complete very quickly - say 15 to 20 minutes or so. The stream for the Shadow Copy Components takes a very long time. It can take many days at times. I am trying to find any ways possible to speed up the backup process for the Shadow Copy Components.
07-15-2020 09:58 AM - edited 07-15-2020 09:59 AM
@Hamza_H I do not understand this comment. What do you mean about deduplicated data activated on the OS?
07-15-2020 03:49 PM
07-16-2020 12:29 PM
The DFSR data is *in* the Shadow Copy Components, which is why it takes so long. As others have suggested, your best solution will be to split the backups, per this TechNote: https://www.veritas.com/support/en_US/article.100038589.
You can split the backups into multiple policies, and specify the exact DFSR folders you want to be backed up within each policy. You will need to work with the appropriate sysadmin to identify the best solution to backing these servers up. Some of them may be small enough to only need one policy with a backup selection of ALL_LOCAL_DRIVES. This will protect DFSR, System State, and any other drives on the server.
For the ones with more DFSR data, you will need to split them into separate policies. One policy will protect the System State and the local drives, and another policy will specify the exact path to the DFSR folders that your sysadmin wants backed up. If there are 10 DFSR folders, and 8 of them are small, they could all go in one policy and the remaining 2 could be in a separate policy. You can test out performance/backup speeds of the folders and then determine which ones are taking the longest to back up.