Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Forever Forward Incemental Configuration
#11
I think that answer is incredible helpful and it makes totally sense that the method was changed in the past. When it comes to huge backups or network connections, the old method would probably take a long time, so manually merging into a full backup occasionally if needed is way more efficient.

Thank you for sharing that insight!
Reply
#12
Yes indeed, that was a huge help @admin, thank you!

I see the logic behind prioritizing deletions over merges. It's certainly a faster way to do things and honestly, merging endlessly is a good way to ensure the whole chain gets corrupted if something goes wrong at some point (ask me how I know). I'm going to time how long a full backup takes of this system because I've been reading more recent versions of Hasleo are a fair bit quicker than Reflect 8.1 (which is where I'm coming from) and if so, I'll probably just set a policy where a Full is done, then 7 or 14 Incrementals, then a new Full which as you say, will reset the chain. Probably better for consistency. But now that I know the parameters, I'll play around and see what works best.

Cheers everyone!
Reply
#13
OK, so one final question for sanity check purposes. Smile

I'm going to try a different method. I have a daily job setup now that's configured for Incremental but also to perform a full backup after 15 runs. I then set the retention to 1 Full backup and 14 Incremental backups.

My guess is that it will create a Full for the first backup as there's no Incrementals present, then take 14 Incrementals in subsequent runs, then the next run should be a fresh Full, which will then delete the old chain and start fresh and continue in that chain loop.

Do I have that right?

Cheers!
Reply
#14
(2 hours ago)Parallax Abstraction Wrote: OK, so one final question for sanity check purposes. Smile

I'm going to try a different method. I have a daily job setup now that's configured for Incremental but also to perform a full backup after 15 runs. I then set the retention to 1 Full backup and 14 Incremental backups.

My guess is that it will create a Full for the first backup as there's no Incrementals present, then take 14 Incrementals in subsequent runs, then the next run should be a fresh Full, which will then delete the old chain and start fresh and continue in that chain loop.

Do I have that right?

Cheers!
That should work but would mean that there is no backup prior to the current one. If some problem was uncovered with the current system you would not be able to go back to a point just before the recent backup.
Reply
#15
Your specific setting would do this:
- 14 inc. backups are kept, so the 15th backup would merge the oldest two inc. backups into 1, leaving you with again 14 inc. backups.
- After 15 inc. backups a new full backup would be performed. But as there are only 14 now, another inc. backup will be performed and the oldest two inc. backups will be merged again, leaving you again with 14 inc. backups.
- So there will never be a new full backup.

What you need to do to make your config work:
- Set your retention policy for inc. backups to at least 15 or reduce the full backup setting to 14.
- Alternatively: You only want 1 full backup anyway, so you can disable the retention policy for inc. backups completely. Just leave the 1 full backup retention activated.

Btw, as your backup is huge: Keep in mind, that the new full backup must complete first. Only then the old full backup will be deleted. That leaves you with 2x 8TB of space that is temporarily needed.
Reply
#16
OK yeah, that makes sense. I've adjusted the policy accordingly. I'll give it a go and see if that lines up. Thanks!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)