Introducing AX64 Time Machine - hybrid imaging/snapshot software

Wow Isso,

Snapshot and imaging in a single program without messing with the boot record was a seemingly impossible feat until now. I tried it on a 'real' machine and it works like a charm. I can hardly wait until it is released.

Best of luck to you and your crew,
SourMilk out

 

Dearest MarcP,

Yes, it is the thread in HDS forum, and it still has the screenshot of Intel Toolbox showing Software RAID mode.

Many thanks and best regards,

Mohamed

 

Dear Pangiotis,

Thanks for the above information. When one uninstalls Rollback Rx, it leaves lots of remnants. And, they don't put things back to normal. When Image For Windows (IFW), introduced WinRE in late 2012, I couldn't get it to work. Tried many things for days, pulling my hair out. Eventually, I had to reinstall Windows 7 x64 on three machines, which is not very easy like reinstalling Windows XP.

Those who have or had Rollback Rx on their machines, should keep the above in mind.

Best regards,

Mohamed

 

I have had problems when uninstalling RX in the past, the boot sector was messed up and I had to restore it from a backup. I now don't trust uninstalling RX, if I want it fully gone I just restore a full backup which was taken before RX was added.

I haven't tested RX10 yet, I wonder if they have found a proper way to deal with TRIM. They've been cooking the thing long enough anyway! With the latest Intel RAID OROM v11.6.0.1702 some of us will be able to have TRIM on RAID setups; but I don't expect the current implementation of RX to mix well with that...

I for one really look forward to to the full release of AX64 so I can have clean boot sectors and fast snapshoting without having to use RX.

 

Marc, Jim, SourMilk - thank you very much for encouraging words!

Mohamed, Panagiotis - thank you for the information, it's now more clear to me. BTW disabling the TRIM will have an impact on SSD life (as well as performance), because SSD won't be able to re-use the free sectors and will be moving the deleted data back and forth thinking that it's still in use.

 

Panagiotis - I think it's close to impossible for RollbackRX to switch to using dat files, because it will require complete redesign of their system, and will introduce a number of new challenges.

And since they don't use files, they are in big trouble regarding TRIM. I see some ways to correctly handle it, but again it'll take lot of effort. Thus I somewhat can understand why they ended up with such a "hack" solution.

Of course, from ethical point of view they should have mentioned that TRIM gets effectively disabled after installing RBX.

Cyberman - looks like RBX didn't choose a proper way to deal with TRIM, apparently they didn't have other choice.

 

Isso, I'm not so sure about your last statement. If they can intercept all the disk I/O for purposes of managing their database, I would think they could easily intercept the TRIM commands and only allow through the blocks that are not in use in their database. TRIM is just another I/O path (actually OUTPUT only) out of Windows, just like Disk I/O is.

If they're not careful they'll get themselves locked in. The poor SSD management already has me looking elsewhere for another possible solution.

 

Froggie,

Sorry, I might not be clear. Of course, you are right, and it's possible, but the implementation may not be straightforward. It may affect the performance, or the stability.
I judge it from AXTM poject, as we've been working on TRIM support for 6 months already, and still there are some minor problems remaining. It looks easy, but as you start implementing it, a bunch of problems pop up.

So I think they might still be working on a proper solution with intercepting/modifying TRIM (as you mentioned), but being pushed to release SSD support, they might have decided to go with a hack until they have the proper solution ready. Just my guess.

 

So does the software support SSD's with TRIM disabled ?

 

arsenaloyal, any software will support SSD if you disable TRIM. That way SSD will be no different from HDD.

 

Froggie intercepting the trim commands and filtering them is very difficult.
Instead, what they can do (or maybe they already implemented it in the last version of 9 and the new 10?) is to send trim commands from their subconsole (during the defrags of the snapshots).
One can easily check this, if first occupies the ssd with files (until is almost full), then deletes them and then initialize a defrag of the snapshots (and leaves the system idle for a couple of hours).
After that, scan the ssd surface.
If most sectors of the ssd surface are zeros they do use trim; if not they don't and is only a marketing trick.

Panagiotis

 

That's an interesting idea Panayioti, I almost feel tempted to try it - and I would if I had time; unfortunately I'm extremely busy ATM. Maybe somebody can give it a go?

Personally I've been using RX for more than a year now. After Mohamed alerted me some months ago that the RX implementation of TRIM is flawed I made sure to allow enough idle time for all my RX bearing SSDs. I usually leave the PCs idling at the BIOS screen (or at RX pre-boot console) for a few hours every week just to make sure that GC kicks in. I have ran before and after benchmarks and the numbers show that GC does the job well regardless of RX crippling TRIM or not.

 

CyberMan,

Unfortunately your approach won't completely restore the SSD performace, because without TRIM GC isn't aware which sectors it can reuse, and any sector that was written at least once won't be reusable any longer.

Normally, after some time of SSD usage, there is almost no sector on the drive that the file system haven't touched at least once (and this happens very soon if the drive is almost full). If TRIM is not working, the GC will not be as effective anymore at that point, so the performance will decrease.
Moreover, wear leveling will be able to rely only on the overprovisioned flash storage, as it will think that the entire drive is used. As a result the SSD life will be decreased.

That's why TRIM is very important to have enabled, especially if your SSD has little free space remaining.

 

Panagiotis - that's a very interesting idea! I'll check it when I have time

 

Thank you for the advice, Isso, I am fully aware of the shortcomings of GC; but lets not forget that this is what RAID users have to put up with on a daily basis anyway. Leaving the PC idle regularly does bring a part of the performance back. Of course the degree of recovery depends on how optimized the GC algorithms are, and this varies between manufacturer/model/firmware. BTW, I make sure that none of my SSDs are ever more than 50% full, in fact far from it. I currently use a 240GB Sandisk Extreme on my main everyday system and the thing contains only 19GB of data ATM.

You're also right about the shortening of life expectancy; however I still have a couple of old SSDs which I have used on a RAID setup for almost three years now and they're still kicking without any reallocated sectors. I haven't been burned yet, maybe I'm lucky, I don't know. I am now so used to the ease of instant recovery/snapshot software, that this is a trade-off that I can personally live with - at least until the full version of AX64 comes out. When this happens off will go RX, and the red carpet will come out for AX64!

 

Thank you Cyberman, and I agree with you regarding shortening of life, as in my experience SSDs failed mainly because of controller issues.
And if your SSD is less than 50% full, then you probably won't notice any performance difference at all. However SSDs are normally small, and I think most of the users can't afford keeping them half full

Ideal solution for RBX in my opinion is what Panagiotis suggested. If it's not implemented right now, their developers should certainly look into it.

 

I try to install as little as possible on OS disks. I mostly use standalone apps (when available), all of them running from non-OS disks. I like to keep my OS installs as light as possible

Of course this is not always feasible, especially with users who may own small SSDs and have limited alternative storage options.

Panayiotis' idea is very nice indeed, I hope someone will have the time to test whether RX issues TRIM commands during snapshot defrag. Pano, eheis hrono?

 

Since Isso already volunteered, I'll pass.

Panagiotis

 

Back to the point, AX64.

Isso, AX64 restoration should be vulnerable (as all boot to restore programs and sector based programs that use differentials/incrementals) to attack vectors that modify very small files, right? (e.g. if a virus modifies a small driver .inf, and the file position does not change cluster, AX64 won't know about it.)

The images/snapshots will be virus free, but the system won't, until a full restore is performed. Correct?

Panagiotis

 

Panagiotis,

I may not fully understood your point, but even a single byte change in any file will result in a changed cluster, thus AXTM will track it and save that cluster (and later restore it).
So I don't see any problem with small files. Please let me know if I'm missing something.

 

There are some rootkits like TDSS family that use direct access to modify legit drivers without changing their size or their creation/modification time. VSS for example cannot detect the difference between the original file and the modified one but if you compare their hashes or you compare them in binary level they are different.

You can do the same with a hex editor, using direct access to manipulate/overwrite some parts of a file and at the same time to pay attention to not modify the size of the file or the time of creation/modification.

Panagiotis

 

Oh ok now I see what you meant. This depends whether the malware is using direct access to disk, or a partition (volume).

AXTM places its driver under volume, so if a malware opens a volume for direct access then AXTM will track it.
However if malware opens disk for direct access, then AXTM won't be able to track it, and only full restore will allow to get rid of such a malicious disk change.

EDIT: this looks to be a very interesting problem, and although (as you mentioned) it's common for all sector based programs, I think I have some ideas to make AXTM more bullet proof. Of course if a malware is running in kernel mode (apparently it does, otherwise it wouldn't be able to write directly to the disk) then there is no way to block it for sure, but operations like direct disk access could be intercepted and tracked.

 

Thanks
It is a problem because users think that imaging apps are bulletproof (they are but only when performing a full restore).

If you could make it intercept direct disk access activity and display a warning to perform an offline restore instead of a fast restore, would be more than fine for me.

Panagiotis

 

Thank you Panagiotis, that is a neat idea too indeed, will have it in my mind

 

Hi Isso. I really like the idea of AXTM.

I'm a Rollback user and really love it. But i have always disliked the extended boot time issues.

This will not be an issue with AXTM from what i understand but have some concerns with the snapshot useablilty/layout.

I've tried AXTM in a VM and have a couple of requests.

1. Show where you are in the snapshot list

2. Ability to view snapshot list in "tree view"

With Rollback i can clearly see which snapshot I'm in or working from after rolling back to a previous snapshot. This is not the case with your Backup Browser implementation. When i rollback (restore) to a previous snapshot it doesnt show me where on the snapshot list I'm at. This is a little confusing when trying to work out what does and does not exist in this point in time.

Here is an example of what i do often in Rollback

Say if i've installed 5 programs (taking a snapshot before installing each one) and discover that the first program i installed 4 snapshots ago conflicts with some other program.

Restoring back to this snapshot and seeing what programs were installed after this snapshot (because Rollback cleary shows me where im at in the snaphsot list) is very useful. I'm able to see what programs i need to reinstall (minus the offending one) taking new snapshots after each install. When i'm ready to delete the old snapshots i view the snapshot list in tree view and i can instantly see the branch of where the old snapshots belong and the branch of the new snapshots. From here deleting the old snapshots is a breeze.

In summary, if you can add this functionality to your existing Backup Browser then I'll be ready to jump ship.