Rollback RX - PROPOSED KnowledgeBase article

So that means that a 'snap' is a 'differential' rather than an 'incremental'.

A 'differential' contains/represents what has been added to/changed from/deleted from the 'baseline', i.e. it represents what is different from the baseline.

Put another way:
The baseline contains: A, F1 and Q.
There are 27 Snaps in total
Snap 18 is chosen to be consolidated with the baseline.

The differential (Snap 18 contains (information that):
'A' has not changed since the baseline was created and should be left in the baseline when consolidating*
'D' was added after the baseline was created and must be added to the baseline when consolidating and
'F1' was changed after the baseline was created and became 'F2' which must replace the 'F1' in the baseline when consolidating and
'Q' has been deleted after the baseline was created and 'Q' must be removed from the baseline when consolidating.

Therefore the new, consolidated baseline contains: A, D, F2.
* It may not be necessary to record the information about 'A' in the differential, the simple fact that it exists in the baseline and there have been no changes recorded in the differential and it wasn't deleted from the differential should be sufficient.

An 'incremental' contains/represents what has been added to/changed from/deleted from the immediately previous 'incremental', or the 'baseline' if it's the first 'incremental' after the 'baseline' (or, in systems other than RBRX, the last 'differential', etc.).

Put another way:
The baseline contains: A, F1 and Q.
There are 4 Snaps in total
The incrementals (Snaps 1, 2 &3) contain (information that):
Snap 1:
'A', 'F1' and 'Q' have not changed since the baseline was created and should be left in the baseline when consolidating*
'V1' was added after the baseline was created and must be added to the baseline when consolidating.

Snap 2:
'A', 'F1' and 'Q' have not changed since the Snap 1 was created and should be left in the baseline when consolidating*
'D' was added after the Snap 1 was created and must be added to the baseline when consolidating and
'V2' replaced 'V1' after the Snap 1 was created and 'V2' must be added to the baseline when consolidating and V1 is 'forgotten'.

Snap 3:
'A' has not changed since the Snap 2 was created and should be left in the baseline when consolidating*
'D' has not changed since the Snap 2 was created and should be left in the baseline when consolidating
'F1' was changed after the Snap 2 was created and became 'F2' which must replace the 'F1' in the baseline when consolidating and
'Q' has been deleted after the Snap 2 was created and 'Q' must be removed from the baseline when consolidating.
'V3' replaced 'V2' after the Snap 2 was created and 'V3' must be added to the baseline when consolidating and V2 is 'forgotten'.

If Snap 3 is chosen to be consolidated with the baseline:
The new, consolidated baseline contains: A, D, F2 and V3.
* It may not be necessary to record the information about 'A' in the snaps, the simple fact that it exists in the baseline and there have been no changes recorded in the snaps and it wasn't deleted from a snap should be sufficient.

If Snap 2 is chosen:
The new, consolidated baseline would contain: A, D, F1, Q and V2.

If Snap 1 is chosen:
The new, consolidated baseline would contain: A, F1, Q and V1.

Hope this helps the understanding of the differences between differentials and incrementals.
J

 

Thanks RollbackFrog - I think I would find that quite limiting.

 

Essentially yes Jwcca. That's how it works. All of that "consolidation" takes place behind the scenes on a sector-by-sector level. Differentially.

The best and most simplest and accurate way to view RBRX is to not look at what's going on the disk, but to look at each snap as What You See Is What You Get. To the Windows' OS, Each snapshot is 100% independent from others. RBRX kernel does that. Read the patent on it.

Just a note: Disk space is not freed up till all references of file X are removed from all snaps. 50 snaps can reference file X, with hardly any disk space being consumed. If file X was a 1GB movie referenced in 50 snaps, the disk space would only reflect 1GB consumption. And a handful of bytes for housekeeping for each snap. Not 50GB.

 

Froggie and Taotoo:
..And what would happen if the snaps prior to your choice for re-baselining are different? Then the re-baselining operation would not incorporate those changes. The re-baselining can only look at the current snapshot you picked. Changes before and after are not included. What you see is what you get.

 

I was watching the wife use her rig and build up a set of snaps something like so:

0- Baseline
1- Snap of baseline for fun
2- Snap of baseline for fun again
3- Install graphics material
4- Install graphics plugins
5- Install camera control software
6- Install photo cataloging software
7- Install visual c environment

Rollback to 0. Not reset, not rebaselined, but roll.

8- Install fractal renderers
9- Install Lightroom

Rollback to 7

10- Install Notepad++
11- Install Word only
12- Install Lightroom

13
~
~
28

Observations you'd make if you were watching.

0-7 was like a build out, installing things.
8- she wanted to see what some fractal renderers looked like, and did so on a "clean" system by rolling back to baseline. She forgot she did that and continued building the system up by installing Lightroom. Ooops.. didn't want the fractal stuff. So she rolled to 7 and continued there. Install Lightroom, Word, and Notepadd++.

She continued on from 13 through maybe 28, taking a snap after each install. Stopping at 28 she updated baseline 28. The finished system. The new baseline does not contain the fractal render material. And that was expected. The new RBRX system does not contain any snapshots now either.

Now the new baseline has the effects of 0-7 and 10-28. 8 and 9 are not present. Fractal stuff gone. Install #1 of Lightroom gone.

---

Reset to baseline = Return your system to the beginning when you first installed RBRX. Or return it to the future condition generated by the next function below. Kills all snapshots

Update baseline = Resets the system to the current snapshot. Kills all other snapshots. Makes currently running snapshot the new starting point. All future snapshots are now parent/childed from here.

Reset, Update, Rollback, Baseline, Snapshot or snap.. Semantics here are important when explaining this material. And any F.A.Q. and tutorials about the program should adhere to how these terms are used within the program.

In context of using RBRX I've come to use "rollback" as a term for transiting through and moving among snapshots. Into the past. Into the future - if my system is set on a snapshot in the past. Be aware each new snapshot is built on the the foundation of the current snapshot which may contain elements from other snaps.

The text on the Baseline manager's dialog is accurate and the program does what it says it does. If you want to gain confidence in using this program then experiment around with it and get a feel for it. Once you do that it can become a very potent tool.

It is not a backup solution. Never ever ever. So if that's what you need you need to consider other options. I would never ever trust a large cache of data or archive to this program. I follow the principle of keeping things as simple as possible. And as you can see RBRX adds a lot of complexity in how data is moved around.

Pictures, Audio/Video, Personal Information, Documentation, Text. Things like that tend to be updated in a manner that is not suited to RBRX. Once or twice then left alone permanently. It is perfectly fine to create that material and manipulate it on an RBRX system. But to have your long-term material managed and archived on an RBRX-controlled drive for the longer term.. DISASTER!

 

Thank you Keatah, using your information I'd be able to use RBRX properly as long as I knew what was done in each snap, such as:
"snap 8, follows the baseline 0 and fractal renderers were added."

Is it possible to add comments to each snap to describe what was done or do you have to keep track of that yourself?
(I assume that when listing the snaps it shows the previous one on which it's built?)

0- Baseline
1- Snap of baseline for fun,_________Based on 0, Comment: nothing done
2- Snap of baseline for fun again,____Based on 1, Comment: nothing done,
3- Install graphics material, _________Based on 2, Comment: installed graphics material
4- Install graphics plugins, __________Based on 3, Comment: installed graphics plugins
5- Install camera control software, ___Based on 4, Comment: installed camera controls
6- Install photo cataloging software, __Based on 5, Comment: installed photo cataloging, added photos on C: to test cataloging,
7- Install visual c environment, _______Based on 6, Comment: installed visual C

Rollback to 0. Not reset, not rebaselined, but roll.

8- Install fractal renderers, Based on 0, Comment: installed fractal renderers, lost photos on C: that were added in snap 6
9- Install Lightroom, ______Based on 8, Comment: installed Lightroom, added photos on C: to test modifications using Lightroom,

Rollback to 7

10- Install Notepad++, Based on 7, Comment: installed Notepad++, lost modified photos on C: that were added in snap 9
11- Install Word only, _Based on 10, Comment: installed Word
12- Install Lightroom, _Based on 11, Comment: installed Lightroom, tested Lightroom with photos added in 6

13- xxxxxxxxxxxxx, ___Based on 12, Comment: installed xxxxxxxxxxxxx,
~
~
28

If the photos were on a different partition then the modifications in Snap 9 would not have been lost.

 

That's what I would assume (despite the manual possibly suggesting otherwise).

Re use of the term "merge" - in this context I always assume we're referring to a destructive merge, rather than a 'keep everything' merge.

 

I totally concur!!

 

Experienced users of Rollback know exactly what it does when either DELETING snapshots or re-Baselining a system. The term MERGE has evolved over the past few years (whether relevant or not) when referring to any incremental imaging system (of which Rollback really is) that provides a merging feature (Reflect v6, AX64 Time Machine, Rollback RX, etc.).

When "merging" any time based PARENT/CHILD related data system, the merge refers to RELEVANT data being brought forth in time from the time point being merged forward... irrelevant data (data not in the time point being merged TO) is always lost in the process (why, because it's irrelevent to that time point). Reflect v6 does this when it does its automatic incremental merging operation, same for AX64 Time Machine when you DELETE (really merge) one of its parent/child time points (incrementals), and Rollback does exactly the same thing when a snapshot is deleted (like AX64)... the results for all are exactly the same as far as relevant data is concerned.

I just decided to use the term all the relevant application authors were using in their product descriptions... MERGE. Maybe we need to consult with Merriam-Webster and come up with a new term... how 'bout Froggled?

 

That's what you and Alex got after reading all this yucky stuff...

 

See Froggies answer, he pretty much sums it up perfectly.

That's exactly right. As always, Froggie has all the answers

 

Train spotting or fishing are good hobbies...Fresh air, good for the troubled soul.

 

So a quick update on where we're at.

I've sent this off to the various parties that be, and we'll announce on here when it's a knowledgebase article. No promises but we're optimistic we can work with this.

Good job Froggie!

 

Its good that your team is looking at this since they were not able to conceive of these problems on their own. Maybe they will learn something, maybe HDS will then change the marketing since HDS is now aware that Rx is not able, on its own, to protect against any and all conceivable problems.

 

We've talked about the marketing. It's not changing.

 

Its nothing short of a bullying campaign...Aside from what? 4 or 5 members its attracted little interest of any worth....Childish, this could have all been done by pm's or direct contact with Horizon.

 

@jwcca:
Yes you can enter comments. But I discovered an instability in RBRX at this point. That's ok. It's on a testing rig.

Yes she did keep them in chronological order. Proceeding right down the list. Your comments are accurate as far as I was watching and remembering. RBRX is simple stuff once you learn to treat each snapshot as WYSIWYG.

The statements about the presence or absence of where the photos are is also right.

It really is pointless to RBRX a data drive. Put it on a different partition/drive.

 

Probably. But the people that lost data would disagree. At the same time any advanced tool requires some hands-on familiarization and time to develop understanding. And then you can't ignore that Windows Updates has been proven once to be fatal.

There are times I like to beat things up like so - either to help out users or make a product better.

 

You REALLY don't want to use that, check the Urban Dictionary and you'll see why.

frazzled a bit brain-fried; lost and confused; not functioning properly; slightly stressed

fraggled affected by an intoxicant, especially by substances that yield THC, a bit like frazzled but you no longer care about your problems

 

And people do appreciate your clear, concise help Keatah, don't let CH dissuade you from carrying on.

 

Giving an opinion is not dissuading...I stand by what I see it as...As I stated it seems to be of interest to a core of 4 or 5 with the occasional comment by other members...I've said my piece, I'm done.

 

And I gave my opinion....FFTD

 

After careful consideration and deliberation with the wife. Let me tell you where I think the problem lies. And the problem I'm referring to is data loss due to RBRX. Some of you may not like it. Some of you may not agree. And that's ok.

The short version:
It's the user and today's contemporary documentation. Not Windows or its Updates. Not RBRX and its bugs.

The long version:
Part of an article we are preparing. I may post some snippets here.