Switching target drives


Author
Message
Stefan
Stefan
New Member
New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)
Group: Forum Members
Posts: 6, Visits: 5
I have two external USB3 backup drives which I would like to rotate keeping one in the car and the other attached to my PC.

I have them set up as P and Q (as alternate drive)

If I'm running full, differential and incremental backups is there any best practise. Should I for example schedule a full backup (manually do a full backup) after switching drives?

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)
Group: Forum Members
Posts: 3.4K, Visits: 25K
Make sure both the P and Q destination paths are stored in your definition file.  Use the "Alternative locations" feature to accomplish that.  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.

In terms of best practice, if you want to use a GFS strategy (Grandfather-Father-Son, i.e. 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.  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.

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.  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.  If you're not familiar with this strategy, Macrium has a nice animated demo of it here.

Edited 17 July 2018 11:06 PM by jphughan
Stefan
Stefan
New Member
New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)
Group: Forum Members
Posts: 6, Visits: 5
Hi jphughan,

Thanks for your helpful reply.

Could you clarify, if I specify for example retain 3 full backups. Does Macrium count the full backups on the target drive rather than increment the number of backups internally. I believe that it counts the backups on the target drive.

Do I understand correctly that Incrementals Forever with Synthetic Fulls can only have one full backup on a drive. If yes then not sure this would work for me as I would like to retain some history going back over time in case I found I needed an earlier version of a file.

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)
Group: Forum Members
Posts: 3.4K, Visits: 25K
Hey Stefan,

Reflect only counts the number of backups at the destination it's working with.  My point about losing more history than expected was a scenario like this:

- Your schedule specifies Full backups every Sunday night, and your retention policy specifies 3 Fulls.  Your normal plan is to rotate disks each Sunday morning before the Full backup.
- Disk A has Full backups created on 6/3/18, 6/17/18, and 7/1/18.
- On 7/8/18, you connect Disk B so that the Full is written to Disk B that day.
- For whatever reason, you leave Disk B connected longer than normal, let's say until 7/18.  Realizing that you missed your normal rotation day earlier that week, you connect Disk A and run a manual Full that day.
- On 7/22 you keep Disk A connected since it's been out of cycle for a while, and so the normal Sunday Full runs to Disk A as well.

At that point you will have created two Fulls in the space of 5 days, but you will have lost two Fulls that were spaced 2 weeks apart (namely the backups created on 6/3 and 6/17), as well as their child backups.  If you hadn't created that manual Full mid-week, you would still have the 6/17 backup and its children by this point, but instead your oldest available backup is now from 7/1.  So yes, you still have the same number of Fulls on your destination, but you lost more "time history" than normal because your most recent Fulls were created more closely together than the ones that were purged. 

Incrementals Forever with Synthetic Fulls is designed to have only one Full per destination, yes.  You don't technically have to use it that way, but if you're creating new Fulls on a regular basis, then that technically isn't "Incrementals Forever" anymore.  But the desire to retain some history over time doesn't mean it can't work for you.  You'd just set your Incremental retention policy to whatever is required for you to retain enough backups to cover your desired history.  Note that currently, Synthetic Fulls require retention policies to be specified in number of backups rather than number of days/weeks, but if for example you want 2 months of history and plan to have daily backups with weekly disk swaps, you could specify a retention policy of 28 Incrementals, which is 4 weeks' worth of daily backups, but if a given destination is only connected every other week, those 4 weeks' worth will go back 2 months in time. (Side note: A perk of specifying retention in number of backups rather than units of time is that you eliminate the risk of a new backup deleting a significant number of existing backups on the destination, possibly even ALL backups, if you connect a destination that has been offline for longer than usual.)

Another virtue of Incrementals Forever is that it's the only strategy where you always have "one in, one out" on backups (other than running 100% Fulls, but that isn't always a viable option).  In a traditional GFS schedule or even something like weekly Fulls and daily Incs, whenever a Full or Diff runs, the retention policy that deletes the oldest backup also necessarily its child backups.  That means that whenever you run a new Full or Diff, you get one new backup, but you might lose a week or even a month's worth of old backups.  This in turn means that you'll have a fluctuating window of backup history, e.g. "at least 5 weeks, but sometimes up to 6 weeks depending on where I am in the week”, which then means that if you want to always have a minimum of 5 weeks' worth of backups, you actually need to have enough storage to keep up to 6 weeks’ worth.  This gets worse if you perform only monthly Fulls.  With Incrementals Forever with Synthetic Fulls, when you add one new backup, exactly one old backup gets purged, so you never have these fluctuations in the length of backup history available, and this strategy also happens to be the most storage-efficient way to store a given amount of backup history.
Edited 17 July 2018 11:07 PM by jphughan
Stefan
Stefan
New Member
New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)
Group: Forum Members
Posts: 6, Visits: 5
"Incrementals Forever with Synthetic Fulls" sounds interesting and I'm running a daily test to try and understand better.

Have a couple of questions though:

How robust are Incrementals Forever with Synthetic Fulls? If I have 30 incrementals and one full backup, what happens if an early incremental gets corrupted, doesn't this mean that anything newer than the corrupted interim is lost?

How would I generate new full backups with "Incrementals Forever with Synthetic Fulls"? Would I have to do this manually or can this be automated?

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)Most Valuable Professional (4.9K reputation)
Group: Forum Members
Posts: 3.4K, Visits: 25K
If a Full or early Incremental is corrupted, then every subsequent backup is unusable, yes. That’s true with any backup strategy, though. The difference of course is that with Incrementals Forever with Synthetic Fulls, there’s only one set per destination, which is precisely why I only recommend this strategy to people using a disk rotation. But yes, you do end up with fewer total independent backup sets than you do with something like GFS. The benefit is simplicity of backup scheduling and storage efficiency. You have to decide for yourself whether those benefits (and whether a disk rotation is enough of a risk offset) to make that strategy appealing to you. Every strategy is a tradeoff, though.

To your second question, you can certainly run multiple Fulls either by running them manually on occasion or by formally adding a schedule entry for them and specifying a Full retention policy greater than 1 backup. Again, that by definition isn’t “Incrementals Forever” anymore, but that’s not necessarily a problem since that’s just a label for a particular strategy, and if that’s not ideal for you then fair enough. That said, if you’re going to capture Fulls on a regular basis, then Synthetic Fulls may or may not be the best way to go. Enabling Synthetic Fulls when capturing Fulls on a regular basis is something you might do if for example you had storage capacity constraints, and therefore you might decide that you want to have monthly Fulls and daily Incrementals, but you you only needed to retain the most recent week of backups, and you wanted your Full to be “carried forward” throughout the month until your next regular Full ran, and then that new Full would eventually start getting carried forward. Alternatively, if you wanted monthly Fulls, daily Incs, and only a week of daily backups retained at any given time, you might prefer to disable Synthetic Fulls and allow Reflect to use Incremental Merge instead. In that case, at the end of a given month, you’d have the most recent week of daily Incs, then the Full from the beginning of that month (NOT carried forward, so it’s still a backup of your data as it was when originally captured), and then the Fulls from however many previous months you were retaining. Or if storage wasn’t a constraint at all, you could disable the Incremental retention policy entirely so Reflect only deleted them when the parent Full was purged, in which case you’d have Fulls and all
of the child Incrememenals that were ever created for it — but that’s of course more storage consumption. Again, every strategy has its tradeoffs.
Edited 23 July 2018 2:07 AM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search