On my PC, for a Full Backup of a large Volume of Data, ATI2020 is much much slower then ATI2018
I was and I am still trying to understand another problem (= huge incremental backup versions) encountered with Volume Backups of AIT2020.
I therefore decided to create with ATI2020 a Full Backup Version of my large amount of Foto File data (around 800 GB) followed by an Incrental Backup Version. The Full Backup Version resulted in a .tibx File
I was quite poorly surprised: with ATI 2020 the Full Backup Version of the volume took 6hours and 47 Minutes (while with AT2018 it took only 1hour and 28 minutes, that is quite fine with me).
Why, in this particular case (Full Backup of a large quantity of Foto Data) , is ATI2020 such poor in comparison with ATI2018...while ATI2020 claims to be faster?
The eventual Incremental Backup version took with ATI2020 ***approximately*** the same time as ATI2018: around 35-40 minutes (which I consider to be a good time and I am quite satisfied with it).
I will now make tests with ATI 2020 File/Folder Backups and hope to get substantially shorter times for the Full Backup Version pof my lösarhge vamount of data..
Here is (for the the Backup of the 709 GB worth of my Data on the USB 3.1 Gen 1 SSD Volume that consists mainly of Foto-Files) the comparison of the:
size of the Backup-Files for a Full-Backup Version: 774.xxx.xxx KB , 632 xxx xxx KB and 718 xxx xxx KB
time required to create a Full Back-Up Version: 1h28, 2h21, 1h53
On each of the two lines/rows above, the first figures are for Volume Backups definitions created with ATI 2018, the second figures are for Volume Backup definitions created with ATI 2020 (= tibx Files), and the third figures are for File/Folder Backup definitions created with ATI 2020 (all of them without the specfication of an ATI provided compression)
Please note, that I made these measurements while performing on the same PC some few other light-weight activities. Therefore the timing figures are very approximative
Even if the figures are different: after my 10- year experiences with Windows 7 backup, I consider all of them to be excellent. Since in my case, it is the size that matters most, my preference actually goes to volume Backup into tibx Files. But I can imagine, that after gaining more experience with ATI 2020 my preferences will either change ....or get re-inforced.
At this time, I am especially interested to learn more about the ATI 2020 merge (for Volume Backups) of Incremental Backup versions into a Full Backup Version (in a scenario without Differential Backups). If that merge is done intelligently (e.g. to optimize or at least to reduce the time required for a Recovery): I could become a fan of such a solution.
The speed of the source and destination disk, as well as the compress level and priority assigned to the task will have an impact on backup time.
It is often mentioned that ATI is supposed to be faster, but I do not recall ever seeing that claim.
As photos are usually already compressed, I am surprised that you achieved substantial savings in space as ATI uses sector based backup.
I am not sure what you are getting about merging incremental versions into full versions. With ATI 2020 the full and the associated incremental versions are included in the one *.tibx file (if large the file may be split), and the cleanup process involves removing a full backup and the associated incremental backups. The inability to keep full backups and delete associated incremental backups is one of the things I do not like about ATI 2020.
Ian
Hello IanL-S,
Deleted incremental backup versions are no longer deleted together with the full backup, but only removed from the backup chain.
Note: this issue has been identified in one of Robert's other topics in the ATI 2020 forum as being caused by file system corruption which in turn has forced the backup to switch to using sector-by-sector method for the backup, resulting in significantly larger incremental files.
I need to come back to my Post #2 in this thread.
Yesterday, I created a new ATI 2020 Incremental Volume Backup Definition for that SSD which I use to store my very large number of photos. To my surprise, the creation with ATI 2020 of the original Full Backup Version took substantially less time than a previous creation of (I believe) the same data.
Instead of 2h21 that I reported in Post #2 for my previous test, yesterday that took only 1h43. I have no explanation for that time difference: the tests have been done with the same SSD Device (Source Data for the Backup), with the same Disk Backup Drive, with the same USB Ports and Cables, with the same PC (that was both time only slightly busy with other activities)....Who knows whether that was just because of another weather?.
Even though I have no explanation for that time difference,, I thought that I should report the new shorter time, in order to avoid to create unfairly a too bad view of the performance of that type of ATI 2020 Backup. In the next future, I can not afford to spend time in order to try to understand.
IanL
My apologies - now I believe to understand what you were meaning below.
Since I am not familiar with how ATI works, could I please ask you what you mean by " The inability to keep full backups and delete associated incremental backups is one of the things I do not like about ATI 2020 "? .
What exactly is ATI unable to do? With which kind of delete?
Thank you very much in advance to help me understand something that could perhaps affect my use of ATI.
-------------------------------------------------------------
To provide feedback to some of your descriptions in Post #3
1) On the subject of: "As photos are usually already compressed, I am surprised that you achieved substantial savings in space as ATI uses sector based backup".
I do not have only compressed .jpeg Files but I also have `quite large uncompressed RAW Foto Files (.DNG files as well as others RAW files like .NEF). I guess that ATI could compress them quite well.
I do however not know, if this is sufficient to explain the not-neglibile difference between the Total size of all Files that have been backed-up by ATI and the total size of all backup-versions of these files.
I believe, that when time will permit, I should do some verifications, in order to be sure, that ATI is really backing-up all my photo files and that the size-difference id not due to some files, that ATI did not back-up ..
--------------------------------------------------------------------------------
2) On the subject of "I am not sure what you are getting about merging incremental versions into full versions. With ATI 2020 the full and the associated incremental versions are included in the one *.tibx file (if large the file may be split)"
I see two potential advantages (there may be more than these two, but they do not come actually to my mind) of this merge.
a) the first (probably not very substantial) advantage: by merging all backed-up versions into the same .tibx file, the number of backup-files gets smsaller and the probability that a user like me delete a wrong Backup file gets smaller. Also it is simpler for a user like me to have an overview of all Backup files
b) the second potential advantage (but I do not know if the ATI developpers tried to exploit it): it could be possible to do a sort (for example a sort based on the Disk block-Nbr) of all recorded changes. Then depending on how ATI is being programmed, if the same information has been changed multiple times, the Recovery could limit itself to write only the last version of the modified data (as opposed to write it one time based on the content of the Full Backup version and then one additional time for every one of the multiple changes)..
Also, this could reduce the number of Disk Operations that write only one block at a time; and increase the number of Disk Operations that write multiple adjacent blocks at a time. On some platforms, it is much faster to write 3 adjacent blocks with one single Write operation than using 3 Write operations that write only one block at a time.
That too could result in substantial performance improvements. Notice however, thatt I have never done any kind of programming on a PC and I do not know, if Developpers of PC Backup/Recovrery software have the possibility to write multiple adjacent blocks at a time.
But on the other side, the Sort will require some time.But that could be done at another time than the time of the Recovery (which is often valuable or critical time,. if the user needs to have rapidly his recovered PC and recovered data available)
Robert
Robert, if your uncompressed raw photo files can be compressed to achieve a saving in their size by other utilities like 7-zip, then ATI should also be able to achieve the same savings for those files.
On the way the new incremental .tibx files work, there may be some saving in size with integrating the incrementals into the same file as the full, mainly because of the savings in not having extra 'packaging' around that data in the form of heading / footer type data because this is already present in the initial .tibx file of the chain. This is just speculation on my part.
I agree that having all the files for the version chain contained within a single .tibx file represents an element of security, as users are unable to delete any individual incremental file by this design, and hopefully these files are less susceptible to corruption etc with longer chains of such files.
Reference your point b) - ATI has always restored files by starting with the newest incremental file (unless a different file was selected as the restore point in time) and then walking backwards through the version chain, keeping the latest changed data without any need to overwrite earlier files that would be restored if the opposite approach was taken.