Introducing AX64 Time Machine - hybrid imaging/snapshot software

So what you are saying is that DS has never failed any user ever in the history of the product? Quite the claim. Besides your own experience do you have any way to validate this claim?

Anyway, folks were just making a suggestion. Clearly AX64 is not for you so I do not see why you are bothering with this discussion. WE will not change your mind and you will not change ours. Lets agree to disagree and be done with it.

 

Well said

 

Hi Isso
What log-Files do you mean exactly ?
(My original Post:
After updating my SSD-Firmware (Samsung 840 Evo 128 ) it seems to be impossible to restore to earlier Snapshots.
Does someone know a Solution ?? )

 

The logs may be collected/found as follows

Open AX64 and right click on the AX64 Icon or name & version number (top left corner of the window)(this would be the window that you would open to create a manual snap, not the full browser window). Left click on "About AX64 TimeMachine" and then click on "Collect Logs". Save the logs and then send them to Isso.

 

ax64 site is down?

i was trying www.ax64.com

 

Works for me

 

Aaah!
Thanks. I didn't Know.

 

site is back again

 

It feels strange to miss a software. Lol. Keep up the good work guys

 

Will verification takes time like usual imaging programs? Then one advantage of AX64 compared to normal imaging software is partly gone. Or do you have a solution for "quick" verification?

Werderforever

 

WF, there is no such thing as QUICK verification

Basically there are only two types of verification... in both cases the entire saved image must at least be re-read. In one case (the faster of the two), the image is re-read and an arithmetic checksum algorithm is performed on the read data. At the end of the particular read (block/file/whatever) the checksum that has just been computed is compared against one that was written when the image file was created. If they are the same, the data is most likely in tact... at this point in time.

The second method requires a byte-by-byte compare between the created image file and the actual data still on the system. This requires an excessive amount of file reading and the system file lock must remain in place while this goes on. If the compare is successful, the saved data and the LIVE data are the same... at this point in time.

At any time in the future, your saved image(s), when needed, may not be as they were when you created them and ran the verification. This may be due to disk corruption, faulty data path hardware, or a myriad of other problems that occasionally plague computer hardware.

To be sure the data or hardware has not been affected along the way... periodic checksumming of the saved data is best performed. This should at least be able to tell you if the saved image data has changed along the way... hopefully BEFORE you actually need it. I offer no methods to do this efficiently... it's just something to consider.

 

hi Pete! Immediate restoration is really not much quicker than checksumming the image... especially with today's high speed processors, but clearly there's a better "feelgood" associated with the process.

But later on... you'll just never know 'til you try to use that data. A periodic restoration (for checking purposes) will be a bit cumbersome... but can be done with AX64 if needed.

There's really not a "good" solution for the potential problems here...

 

Can I safely defrag the HD my AX64 backups are on? I do only manual backups. Sorry if this has been asked before. Now I am thinking there is no need as my primary drive is SSD and should I restore, it will straighten things out. Thoughts?

TIA

 

I don't really know much of this but when it comes to checksum and verification wouldn't the checksum change as soon as you delete one snapshot since, from what I've gathered, this data merges with other snapshot(s)?

 

RollbackFrog,

many thanks for your explanation. I have meant something like the arithmetic checksum algorithm, but I don´t have had the right words for that (you see, English is not my motherlanguage) and it´s sometimes difficult to explain, what I mean.

It´s clear, that verification needs some time.

Werderforever

 

SanyaIV, if AX64 TM implemented a CheckSum feature, it would be included not only in the snapshots themselves but the recreated snapshot from the MERGE process as well, basically each time a new snap (original or merged) is created... that's the only way that makes any sense.

 

The restore function is a TRUE restore... exactly the usage geometry at the time it was imaged. That, of course, will make no difference to an SSD as you say... it really doesn't care about fragmented files.

Defragmenting the snapshots themselves on the separate storage volume does not do anything to the internal data structure of the snapshot... it only organizes the used space on the storage volume.

Feel free to defrag your snapshot storage volume if you'd like... it will not affect snapshot restoration.

 

Will doing a restore with AX64 (or any other restore program) undo any encryption that the new security threat called "CryptoLocker" do to your files?

Thanks.

 

So the checksum would be to make sure that the snapshots haven't been altered once they've been created but it wouldn't help in detecting errors in the creation stage? I mean, when you make a snapshot and lets say the snapshot somehow is broken already when creating it, the checksum wouldn't detect this, it would just determine whether the broken snapshot had been changed after that?

I'm not sure if I make any sense or if my situation I painted up is even valid.

 

OK, as I suspected Froggy....The reason I asked is some of my manual mergers of late have been extremely slow...45 min or more. I was thinking I might add some speed by
defragging.