How do you optimize 'data anchoring'?

No, because I tend to update my "rollback" snapshot after I've done a full-scan of my system. In any case, after that things are scanned in real-time using the RTM, including email.

Even if you don't anchor, it could be argued viruses could attach themselves to the next snapshot when you copy/update it. Providing your system is clear upon each scan, there shouldn't be a problem.

 

If a person can keep and maintain a clean Snapshot, then all Snapshots updated with THAT Snapshot are also clean. Anchoring is the one question-mark in that process, so I exlude this otherwise excellent feature. Yes, I am strick with keeping my Snapshots clean and I intend to keep it that way!

Acadia

 

Ok, so why bother with data anchoring as a feature? If people can just update other snapshots with that one clean snapshot as you suggest, there isn't really a need for data anchoring then other than potentially reduce the size of snapshots?

I use data anchoring because I don't update my "rollback" snapshot that regularly, and if something happened and I had to boot into that snapshot, any work done since would be lost. With the work anchored, they will be current whichever snapshot I boot into. That's how I see it.

By the way, I do backup important documents daily as a means of another recovery measure.

 

That is interesting, Tony.
I have the habbit of 'updating rollbacks' by first restoring from archive/image and than implementing the desired updates.
And then refresh the archive/image, because I want to be sure that the archive/image isn't updated with 'features' that I forgot about.

 

I see your point, Acadia.

But even with 'quarantained snapshots', at some point in time you need to open your probably infected documents.
And if your security software didn't catch the potential disaster, what does that quarantain do for you?

 

I don't use any archive image to restore from. I do have a baseline image of the system from June 2002, which thankfully I haven't yet had to use.

 

Tony, we all have different ways of using this incredibly flexible program. I update one of my ten bootable Snapshots, and six unbootable Snapshots, AT LEAST once a day. I can see why this Data Anchoring would be so valuable to others and have stated so. When it comes to my security considerations it's just that I want all of my Snapshots to be COMPLETELY unconnected to one another, but I can definitely see why others would not; Data Anchoring is a very thoughtful feature of this program.

Acadia

 

?? Where would they have come from?

Acadia

 

Another point to mention is that if you have a great deal of HD space, such as you have previously said you have, doing it the way you do things isn't a major problem, but others who don't have that luxury seek other ways of using this great program. The promised snapshot compression Todd hinted at recently may change ways of using this program for that latter group of users.

 

How then do you handle harddisk failure?

 

I have created a copy of the initial installation, I have installed windows from scratch into an empty snapshot, I have created and updated archives on an external drive. I have restored from that external archive into an existing snapshot to undo some software test.
I have familiarized myself with data anchoring by testing this in the several snapshots. I was happily surprised to see that the anchored data was availble in the empty snapshot, while ISR wasn't yet installed.

Currently I have a frozen OEM snapshot (and archived), a work snapshot (and archived), a game/test snapshot, and waiting an empty snapshot for another fresh installation.

What I still want to test is recovery from archives after harddisk failure.
I do want to familiarize myself with all the features and limits.

 

As I said previously, I have a baseline image of the system at factory level. All my important documents are backed up. In the event of a HD failure, I'd suppose I'd get a new HD, restore the image and documents onto that new drive.

 

Sorry for asking, my expertise is misunderstanding: does your solution mean that in case of 'new harddisk' you are going back to the installation of June 2002?

 

Yes, basically, that would be right, but in this day and age of fast DSL it's not a problem to update specific software, and, as I say, the critical data is backed up and so easily restored.