eazFix/Rollback RX and defect snapshots

I wouldn't call it 'grinding' (to me, that would be ominous!), but I have noticed that booting-up with the current (Sept) Rollback build simply takes longer than the prior (July) build. Otherwise, so far so good, as it is working very well for me (as did the July build).

 

Today is the day 'I eat my words'. Previously, I said that I have not experienced wilbertni's problems by using RB's defrag within Windows... well here's what just happened...

Last night, I opened RB in Windows deleting several snapshots (reducing my snapshots from 23 to 15) and I then ran RB defrag. I then shutdown my system. When I awoke this morniing, I started my system up and noticed that F-Secure (my trusted AV & Firewall) would not update automatically (as it normally does at startup). I couldn't even open it to attempt a manual update!

I figured that the system probably didn't startup properly, so I did a restart and experienced the very same problem. Well, since F-Secure was working just fine yesterday, I decided 'to Rollback' to yesterday's last snapshot ...which produced a dirty-disk (chkdsk) scenario! As a matter of fact, every snapshot I attempted to restore (from this past week) was corrupted! I have no way of knowing for sure that the defrag from within Windows caused all of this, but it is in line with what wilbertni has reported.

So after experiencing several corrupted snapshots, I restored my system using a recent ATI backup (thank you Acronis!) and all is now working well. But 'my bubble has burst' and I will now proceed more cautiously with RB, heeding wilbertni's advice to only allow RB to defrag automatically in its startup console.

~pv

 

I'm sorry to hear about that, PV.
Your information is very important, since it confirms that healthy snapshots are turning into defect snapshots.

Thank you very much for sharing this.

Last Friday I took the time to write down each and every step that I take to get defect snapshots, including screenshots of every step.
What I understand so far is that you can't take shortcuts when you want to reproduce the error.
I named my document The illustrated tutorial to create defect snapshots in 12 easy steps and sent it to eazSolutions support.

The bug is getting the attention it deserves, but as you have experienced now, it's kind of a rare situation.

Again, your information is highly appreciated!
I included your information in the support ticket, would you be able to create a screenshot of the snapshot structure that we talk about?
I understand that you are back to baseline now, but could you fastforward to 23 snapshots? And perhaps repeat the act of doom?

By the way, as I understand it, the baseline would be bootable.

 

pvsurfer,

Do you remember that you restored to any snapshot before, and that they were healthy then?

 

Yes, a great many times, and without any recognizable problems (that is until this morning)!

Ever since installing the July build, I have been operating in essentially the same manner as far as number of RB snapshots, RB defrags, etc. Since then, I can't identify anything significant that has changed in my computing activities; certainly nothing in the past few days - that's the most bewildering aspect of this elusive RB/EAZ 'gremlin'.

 

Allright, that is very important information, PV.
Do you think that I would be able to reproduce your situation if I do the following:

Code:

Start with baseline
Create 23 snapshots in a row
delete 15 snapshots
snapshot defrag
restore to final snapshot.

Or is there anything extra that I need to do, as far as you remember?

 

My actions are more complex than just doing what you propose. You see, I tend to build-up a large # of snapshots quite rapidly, so I make a practice of deleting some every day, always following up with a defrag. Then once a week I update my baseline snapshot (the last time I did that was a week ago today).

Btw, last night I deleted 8 snapshots (not 15). I started with 23 and ended with 15 snapshots, which I then defragged. Had I not run into the problems I reported this morning, I would have again updated my baseline today. Instead, I have once again uninstalled RB.

 

PV,

I'm curious, did you let Windows proceed with the chkdsk or did you cancel before you tried the other snapshots?
When I have this situation, I always cancel, because I figure that only this snapshot is defect.
I usually can restore other snapshots just fine.
If you proceed with the chkdsk, that might damage other snapshots, at least that is what I'm telling myself...

What did you do?

 

Same thing as you. If I get a very dirty disk when using RB, I no longer want any part of that snapshot, so I try restoring another one.

 

Are u sure it should be like this?
When I did like this before, people here criticised to do so.

 

Snap - In the past when I had a dirty disk the snapshot was always damaged so I restore to the one before or another

 

"Different folks, different strokes"

From my viewpoint, that's why I use(d) RB. The dirty disk problem is snapshot-centric, so why not restore to a clean snapshot? ...of course that presumes RB/EF is working the way it should - which it (apparently) still is not.

So as was the case back in the May-June period, I again had to rely on ATI to save my bacon!

 

It's possible that the baseline was healthy too... Did you try that?

 

I did restore the baseline and it appeared healthy, but as I had much more trust in ATI (especially after this incident), I decided to uninstall RB and restore my system using my most recent ATI disk-image.