Group: Forum Members
I have an odd performance anomaly in my backups for which I'm trying to determine root cause and ideally a fix, but I'm wondering if Macrium staff or anyone else might have possible causes that haven't occurred to me yet. First, a description of the backup strategy in question:
1. Every weeknight, an Image backup runs at 10PM (for everything except the Data partition) and a File/Folder Backup runs at 11PM (for the Data partition). I do this because Reflect currently does not offer a built-in method of restoring data from image backups that preserves custom NTFS permissions, and that's important for this system's Data partition. The machine in question is a Dell PowerEdge T330 running Windows Server 2016 and the latest release of Reflect V6.
2. Backups are stored on a rotation of 9 identical WD 3TB USB 3.0 disks -- one for each of the 5 possible Mondays in the month, and one for each of the remaining weekdays, the latter of which are used every week. The Monday disks are used once per month, or less in the case of the "5th Monday" disk.
3. The strategy is Incrementals Forever with Synthetic Fulls, with 7 Incrementals retained. This plus the rotation strategy means that the non-Monday disks contain weekly backups going back essentially 2 months.
I'm going to ignore the Monday disks here since their less frequent use will cause their backup times to differ from the others, and also because this strategy has not been implemented long enough for sufficient backups to accumulate on the Monday disks to trigger consolidation anyway. Looking at the Tuesday through Friday disks, the time to complete the actual backup (i.e. total time minus consolidation time) is approximately 1h30m, nearly identical across all of them -- as would be expected under this rotation strategy. HOWEVER, looking at the consolidation time, the Wednesday, Thursday, and Friday disks complete that operation in approximately 1h25m, but the Tuesday disk consistently takes 3h30m. The logs reflect this occurring consistently for several months now.
Looking at Event Viewer I haven't found any references to activity going on late Tuesday night or very early on Wednesday that might slow this operation down, and I would be surprised if a hardware defect with the Tuesday disk could still allow its write speeds to keep up with the other disks and only affect consolidation I/O. I'm reluctant to deliberately connect the wrong disk on Tuesday to isolate the day vs. the disk or to kill the Tuesday set and start fresh to see if that solves the issue (especially since I'd have to wait 2 months to get my answer with this retention policy), and copying the Tuesday files to another disk and using Consolidate.exe to test that operation on the Tuesday files while they reside on another disk isn't as easy as it might sound because the Full plus first Incremental total about 800 GB.
So at this point I'm just curious if anyone has any ideas as to what may be causing this anomalous behavior or what other tests potentially more feasible tests I can run to determine root cause.