Forever Forward Incemental Configuration

[al3x]

Then the setting/config must then allow all incremental backups in that chain to be auto deleted if there are one or more new full backups. The objective is to avoid manual activity and merging.

They will be auto deleted as soon as the corresponding diff or full backup they belong to is removed, which can be automated by applying a diff or full image retention policy.
So there's no manual activity involved actually 

[Gork]

The latest posts in this thread bring to light the reason I use diffs.  Each of my chains is set up thusly:
FULL - {DIFF - INC x6} - {DIFF - INC x6} - {DIFF - INC x6}

Then after the fourth subset of {DIFF - INC x6} the oldest diff is removed via retention policy.  After a time, I start a new chain with a new full.  After the third FULL is created, retention rules get rid of the oldest FULL, thus completely removing the oldest complete chain.

My main reason for using DIFFs is to easily delete groups of INCs.  But, it also lets me continue a chain without too many INCs relying on each other while not having to run a FULL so often, which obviously takes a lot more time.

While in the past I've used time based scheduling (to include waking the PC when necessary) and created a new FULL on the first of the month followed by a DIFF the next day and each subsequent week of the month and otherwise daily INCs - my current hobbled PC setup doesn't allow me that luxury.  I must now attach an external hard drive for each backup, and I just perform an image backup when I have time - maybe once per week.  Ish.  Maybe twice per month.  Maybe twice in one week if there are a lot of changes.

When I do run a backup, I must to examine how many DIFFs and INCs I have in the latest chain, each time, and make a decision on whether to run a manual FULL (to start a new chain), an DIFF or an INC.  I'm just saying it would be nice to be able to create logic in advance so I can connect my external drive and maybe even just click a shortcut on my desktop that starts the appropriate backup in HBS.

As I thought on this, and tried to set up a backup strategy from Mom, I thought of how much easier it would be for her to keep her backups up to date if I could set her up with something like this.  (I mean, she needs to look at her cheat sheet just to remember how to plug in the external USB drive before starting a backup!)  She sometimes doesn't even turn her PC on for weeks or moths at a time.  So, having scheduled backups based on time isn't really the best option for her.  She might end up in a position, for instance, that she has to deal with a total full backup every time she turns on her PC, even though she has no new data to back up.  She just needs to be able to run a backup when she feels like it, but there is no way I'll ever get her to understand how a backup chain works and how she should decide on what type of backup (full, diff, inc) to use each time.  And she's not going to perform backups regularly if it's a full each time, because it (unnecessarily) takes too much time.

Then I started thinking...  Maybe there are a lot of people who could benefit from this capability.  Maybe it could make HBS stand out.  Maybe it could drum up more business for Hasleo.  As an "IT tinkerer" I don't mind setting something up for my siblings, mother and friends INITIALLY.  But I can't be there to help them along frequently.  I'd like to set something up for them so they can just attach an external drive whenever the mood hits them, click a shortcut on the desktop and not have to think about specifics.

In the end, allowing a simpler process to be set up for an extremely end user (Mom, Grandma etc.) should make it more likely that folks would regularly back up their precious digital lives.  And if Hasleo is the only mainstream imaging software offering the solution, well, that could mean $$$. 

EDIT:
Oh, and I meant to say, with regard to the difficulties streamlining the GUI...  I don't see a reason to mix "date/time schedule" based backups with "state of the chain" based backups.  So, in my head, the simplest way to handle GUI issues is to have the user click on an option to choose one or the other when creating the "schedule" for a backup definition ruleset and the correct window would open with the options available based on that choice.

[Bespoken]

New Manual Cyclic Backup screen
When this setting is enabled, clicking a Backup on the main backup window would use the rules defined here.

The main problem with these is, they only cover some of the settings, e.g. you have a dedicated option just for a new month (what about week, special calendar days or something else etc.). So I personally think those would overcomplicate the options a lot.

I disagree. Yeshis option does have some complication but a little complication is better than no function. I cannot see any way to make it less complicated. Adding a time selection to the "Perform a full backup at ?" would complicate it even further, ie.
- if the option was weekly would the day of the week need to be specified
- same if the option was every second week.

I think my proposal works for those users that want to click Backup and then let the parameters control what type of backup is performed. I am sure this model would satisfy 90% of those users.

[admin]

@All

Regarding the UI design for Chain Cycle Mode, here are my personal thoughts for everyone to discuss.

1. Rules Page (New)

Add a "Rules" page under Backup Options, roughly as follows:

[x] Enable Chain Cycle Mode
[1] [DIF]  - +
[5] [INC]  - +
...

Enable Chain Cycle Mode is a checkbox. Once enabled, use the "+" button to add an item below the current one, and the "-" button to delete the current item.

Each item consists of "quantity + backup type". For example, [5] [INC] means performing 5 consecutive incremental backups.

All the items added above are called a sub-chain.

The program will repeat the above sub-chain.


2. Backup Schedule Page

Once Chain Cycle Mode is enabled, the schedule page remains essentially unchanged, except that the backup type cannot be specified. The schedule is only responsible for "when to trigger" a backup, not "what type to trigger". The backup type is determined by the chain cycle rules.


3. Image Retention Policy

Once Chain Cycle Mode is enabled, the retention policy changes from "retention by image type" to "retention by sub-chain":

Sub-chain  Retain  [N]  [days/weeks/months/years/count]


The above are my personal preliminary thoughts. You are all welcome to continue adding other aspects that should be considered, or to share your own thoughts.

Best regards,

[Bespoken]

@All

Regarding the UI design for Chain Cycle Mode, here are my personal thoughts for everyone to discuss.

Looks like a good approach. How would this apply to a manual Backup? For example, the first time it is selected a Full backup would be performed, then after that it follows the chain rules.

[admin]

@All

Regarding the UI design for Chain Cycle Mode, here are my personal thoughts for everyone to discuss.

Looks like a good approach. How would this apply to a manual Backup? For example, the first time it is selected a Full backup would be performed, then after that it follows the chain rules.

Good question, and I forgot to mention this. The backup menu for tasks on the main page will no longer show submenu items such as Full, Incremental, and Differential. Whether the backup is triggered manually or automatically, it will follow the chain cycle rules. The only exception is the first backup of the task, which is always a Full backup.

[al3x]

The above are my personal preliminary thoughts. You are all welcome to continue adding other aspects that should be considered, or to share your own thoughts.

I think that could work. It's easy to understand and doesn't have lots of different (conflicting) options you would have to think about first.

But there's one thing that wouldn't work with this idea: You can't combine a schedule with a specific manual backup type, for example to force a new chain once a week or every month. Not a must-have for me personally, though, I mostly use automatic schedules.

The backup menu for tasks on the main page will no longer show submenu items such as Full, Incremental, and Differential. Whether the backup is triggered manually or automatically, it will follow the chain cycle rules.

Would it make sense to still have an option in the menu to force a new full backup (and start a new chain)? That might be useful if you didn't update for a long time and want a fresh start to prevent a huge incremental backup.

That could even be combined with a schedule then: There could be a schedule option to reset the chain cycle (= new full backup). Example: You set up your chain cycle with multiple diffs/incs and schedule a chain reset on every 1st (or Saturday or whatever) of a month.

Hope I don't think too complicated

[Gork]

Regarding the UI design for Chain Cycle Mode, here are my personal thoughts for everyone to discuss.

1. Rules Page (New)

Add a "Rules" page under Backup Options, roughly as follows:

[x] Enable Chain Cycle Mode
[1] [DIF]  - +
[5] [INC]  - +
...

Seems like an elegant design thought.  It simplifies things.  While I can tinker a bit with code and numbers, my brain does NOT work well with design and art types of things.  :/

The one problem, as has been brought up, is how to decide when to start a new FULL using what is now being called Chain Cycle Mode - without having to manually do it.  In my backup chain example, for instance, we'd need to know how many diffs were taken since the last full, regardless of whether diffs in the chain were previously deleted.  (I LOVE the term Chain Cycle Mode, btw.  And, I really like the "sub-chain" description as well.  Very nicely done.)

I have two ideas.  The first is more elegant, but might be more difficult to implement.  Each diff image file could contain data on what their part in the chain is.  A diff image file could contain a number in its header which signified where it fit into the chain.  001 would mean it's the first diff since the full in the chain.  005 would signify there had been 4 diffs before it.  So, even if 001 and 002 were previously deleted via retention rules (or even manually) when a backup is started, we would still know when we get to 005 we're on the fifth diff in the chain.  This would allow us to start a full instead of a diff when diff 006  would've started.  The same thing could be done with full and inc image files, though I can't come up with a reason to save that data.  Current retention rules already let you get rid of full chains, and if someone wants to delete prior incs in a chain or sub-chain they're delving deep enough into a project they obviously know what they're doing.

The second idea, and perhaps the easiest to implement, might be to keep a data file for each chain that acts as a "counter."  It would simply increase the count by 1 every time a new diff is created in the chain.  HBS would then know how many diffs had been completed in the current chain, regardless if some of them had been deleted before a backup starts.  This method seems more clunky, but maybe doable.

I would like to point out that with the chain/sub-chain example in my prior post, it is important that the process performs a diff directly after each full.  If a full is performed followed by 5 incs before a diff is created, those first 5 incs would be "abandoned"  and needlessly take up space in the chain.