CURRENTLY NOT CONNECTED TO REALTIMES FULL
Your normal plan is to rotate disks each Sunday morning before the Full backup. Your schedule specifies Full backups every Sunday night, and your retention policy specifies 3 Fulls. My point about losing more history than expected was a scenario like this: Reflect only counts the number of backups at the destination it's working with. If you're not familiar with this strategy, Macrium has a nice animated demo of it here. The typical risk with Incrementals Forever with Synthetic Fulls is that you only have one backup set, and therefore if part of the Full is corrupt or unreadable, it kills all of your backups, but having a disk rotation addresses that because you now have multiple sets stored on multiple disks. I personally use Incrementals Forever with Synthetic Fulls for my disk rotation because it's by far the easiest solution to use in a rotation scenario, the reason being that Reflect only ever performs Incrementals, which means there's never any worry about swapping a disk at a specific time in order to get a particular type of backup created on the correct disk. Otherwise, you can certainly run a Full manually after swapping to a new disk (and that might be desirable if you swapped a disk later than intended and therefore had the most recent scheduled Full go to the "wrong" disk that was still attached), but keep in mind that if you have a retention policy specified, each new Full you create will delete an old Full, so running a few of them in close succession might cause you to lose more backup history than you wanted. Full-Diff-Inc), then you'll generally want to swap disks before a Full day so that you end up with the same pattern of backups on each disk, so if you can swap disks at a consistent time of the week/month, I would design your schedule around that. In terms of best practice, if you want to use a GFS strategy (Grandfather-Father-Son, i.e.
CURRENTLY NOT CONNECTED TO REALTIMES WINDOWS
The alternative would be to switch Reflect to discover destinations by unique volume ID rather than drive letter so that it will find those two specific disks regardless of which drive letter they're assigned at any given time, but if those drives are consistently assigned those letters by Windows and nothing else will be using those letters (both of which seem likely since those letters are far down the alphabet), then you can stick to this solution. Use the "Alternative locations" feature to accomplish that.
Make sure both the P and Q destination paths are stored in your definition file.
0 kommentar(er)
