ATI 2020 Backupdauer .tibx ohne validierung, Backuptime .tibx without validate
Wenn ich einen Benutzerdefinierten inkrementellen Backuptask (1Voll-3Ink-1Voll, 3 Ketten) erstelle, wird nach jeder zusätzlichen Backupkette die Backupdauer erhöht (Die Schreibgeschwindigkeit auf der externen Festplatte wird immer langsamer, obwohl mit einem Benchmarkprogramm immernoch eine sehr hohe Schreib- und Leseleistung erbracht wird.
1. Vollbackup ca 45Min.
2. Vollbackup ca 81Min.
3. Vollbackup ca 131Min.
4. Vollbackup ca 176Min.
5. Vollbackup ca 201Min. (Editiert)
Die Auslastung der externen Festplatte beim Vollbackup der Backupkette ist bei mir ungefähr: Maximale Schreibleistung der externen Festplatte, geteilt durch die Anzahl der Backupketten, geteilt durch 2 wegen Schreib und Lesezugriff auf die Externe Festplatte. 200MB/s : 4 Backupketten = 50MB/s : 2 wegen Schreib- und Lesezugriff = 25MB/s Schreibgeschwindigkeit bei der Vollversion der 4. Backupkette. (Windows Taskmanager - Leistung)
Ist das nur bei mir so?
-------------------------------------------
When I create a custom incremental backup task (1full-3Ink-1full, 3 chains), the backup time increases after each additional backup chain (The write speed on the external hard drive becomes slower and slower, even though a benchmark program still provides a very high write and read performance
1. Full backup about 45 minutes
2. Full backup about 81 minutes
3. Full backup about 131 minutes
4. Full backup about 176 minutes
5.Full backup about 201 minutes (edited)
The utilization of the external hard drive at full backup of the backup chain is about: Maximum write performance of the external hard drive, divided by the number 200MB / s: 4 backup chains = 50MB / s: 2 for write and read access = 25MB / s write speed for the full version of the 4th backup chain. (Windows Taskmanager - Performance )
Is that only for me?
Attachment | Size |
---|---|
Backupdauer immer langer.GIF | 260.53 KB |
Auslastung externe Festplatte.GIF | 220.19 KB |


- Log in to post comments

I can't definitively say if I reproduced the same behavior. I set up a similar backup job with 1 full and 3 incrementals and set the retention to keep 3 version chains.
Each time a full was run, it did seem like it took a little bit longer... up until the 4th full ran, then it came down a little bit again. So up to that point, I though we were onto something.
I will say that my destination was a NAS and not a locally connected USB drive, so there is some variation there. Also, my test machine is much smaller at only about 30GB of raw data so the fluctuation in time that I saw, was not super noticeable, but it did grow for awhile.
What I suspect may be part of the problem is
1) USB disk fragmentation the more data is written to it, it is likely fragmenting more as space becomes less
2) The size of the backup .tib (or .tibx) files if it is a single file per each full backup. I've never been a fan of allowing backup software to create a single large file - that means more resources needed for caching (memory, CPU and the hard drive itself). I also think it leaves more room for error during long writes of these large files. My personal preference used to be to break them into smaller DVD-sized chunks, but that was a bit too many pieces for large backups, so I've been setting them to blu-ray size (25GB) by default for the last couple of years. I really believe this improves overall performance
3) Contiguous space on the disk. Because of the large single file size of a full backup, the more the drive fills up, the less contiguous space is available. Normally, a large file will try to find a block of space in one section, but as the disk runs out of room and as fragmentation worsens, the contiguous blocks of available space become less and less, resulting in less performance of the writes. Compound this by using extremely large backup files, and I think it makes the performance worse.
As an alternative test, my recommendation would be to use a smaller default size for the .tib / .tibx files and see if performance improves (if at all, some-what, or greatly). You'd probably want to start your test with a good amount of free space too, so it's a bit more comparable to when you started your initial test.
Attachment | Size |
---|---|
514672-172930.jpg | 209.24 KB |
514672-172931.jpg | 206.99 KB |
- Log in to post comments

Nächster Versuch mit einem Laufwerksbackup "Benutzerdefiniertes Schema" "Vollständig", ohne Validierung.
Vor dem ersten Vollbackup war die 3TB Backupfestplatte mit etwa 500GB Daten belegt.
1. Vollbackup der Backupkette ca 54 Minuten.
2. Vollbackup der Backupkette ca 81 Minuten.
3. Vollbackup der Backupkette ca 132 Minuten.
-----------------------------------
Next attempt with a drive backup "Custom Scheme" "Full", without validation.
Before the first full backup, the 3TB backup hard disk had about 500 GB of data.
1. Full backup of the backup chain about 54 minutes.
2. Full backup of the backup chain about 81 minutes.
3. Full backup of the backup chain about 132 minutes.
Attachment | Size |
---|---|
514750-172948.GIF | 149.06 KB |
- Log in to post comments

Nächster Versuch mit einem Laufwerksbackup "Benutzerdefiniertes Schema" "Vollständig", ohne Validierung.
Vor dem ersten Vollbackup war die 3TB Backupfestplatte mit etwa 500GB Daten belegt + die 3 Vollbackups des letzten Versuchs.
1. Vollbackup der 1. Backupkette ca 61 Minuten.
1. Vollbackup der 2. Backupkette ca 68 Minuten.
1. Vollbackup der 3. Backupkette ca 62 Minuten. (Beim 2. Versuch, weil zu wenig Speicherplatz)
--------------------------
Next attempt with a drive backup "Custom Schema" "Full", without validation.
Before the first full backup, the 3TB backup hard drive had about 500GB of data + the 3 full backups of the last attempt.
1. Full backup of the 1st backup chain about 61 minutes.
1. Full backup of the 2nd backup chain about 68 minutes.
1. Full backup of the 3rd backup chain about 62 minutes. (On 2nd try because too little space)
Attachment | Size |
---|---|
514752-172950.GIF | 134.88 KB |
514752-172951.GIF | 146.77 KB |
514752-172952.GIF | 148.64 KB |
- Log in to post comments

That's really odd. Makes no sense why the backups slow down so much with the first 3 backups and then start behaving normally with the next 3 while the other 3 are still on the drive and space is running out. Was the default backup size of the .tibx used for both tests too?
- Log in to post comments

Die Backup-Archive (Vollbackups) sind alle ungefähr gleich groß.
Der einzige Unterschied ist, das die Backupzeit des ersten Vollbackups normal ist, alle weiteren Vollbackups der Backupkette aber immer länger dauern.
----------------------------
The backup archives (full backups) are all about the same size.
The only difference is that the backup time of the first full backup is normal, but all other full backups of the backup chain take longer.
- Log in to post comments

Yeah, that's what makes it so weird! The times are getting longer, because the transfer speeds are going down, but why!
Did you try to set the maximum size of the backup file to 25GB and see if the behavior is still the same?
- Log in to post comments

Nächster Versuch mit einem Laufwerksbackup "Benutzerdefiniertes Schema" "Vollständig", aufgeteilt in DVD Größe ohne Validierung.
Vor dem ersten Vollbackup war die 3TB Backupfestplatte mit etwa 500GB Daten belegt.
1. Vollbackup der Backupkette ca 55 Minuten.
2. Vollbackup der Backupkette ca 105 Minuten.
3. Vollbackup der Backupkette ca 168 Minuten.
----------------------------------------
Next try with a drive backup "Custom scheme" "Full", split in DVD size without validation.
Before the first full backup, the 3TB backup hard disk had about 500 GB of data.
1. Full backup of the backup chain about 55 minutes.
2. Full backup of the backup chain about 105 minutes.
3. Full backup of the backup chain about 168 minutes.
Attachment | Size |
---|---|
514962-173038.GIF | 238.28 KB |
- Log in to post comments

I was curious so ran a test myself. Here is the setup
ATI 2020/21400 in use.
BU configured as 1 full - 3 inc - 1 full - 3 chains
Source disk - Win 10 OS disk 1TB M.2 NVMe raid 0 array
Target disk - WD Passport 2 TB USB 3.0 External (attached to MB I/O panel)
Total size of data on disk - 23.6GB
Total size of normal compressed BU - 8.7GB
I let the test run to allow all 3 fulls to complete plus 1 of the inc. for the last full. I found that performance across all runs of the backup were consistent. Full versions completed between 1 min. 41 sec to 1 min 45 sec. Incremental versions completed between 19 secs. and 29 secs. Target disk speed for full versions ranged from 84MBps to 86MBps.
My conclusion here is issue with connection of target drive. Could be faulty cable or case mounted port. Possible failing drive. Possible drop in voltage over USB cable causing disk performance loss (check you PSU for fluctuation of 5 volt rails).
Screenshot of BU activity screen below:
- Log in to post comments

Wenn ich einen Benutzerdefinierten inkrementellen Backuptask (1Voll-3Ink-1Voll, 3 Ketten) erstelle, wird nach jeder zusätzlichen Backupkette die Backupdauer erhöht. Die Schreibgeschwindigkeit auf einer internen Festplatte mit den Backups wird mit dem .tibx Backuptask immer langsamer, der .tib Backuptask hat dieses Verhalten nicht.
1. Vollbackup tibx ca 60Min.
2. Vollbackup tibx ca 88Min.
3. Vollbackup tibx ca 115Min.
1. Vollbackup tib ca 61Min.
2. Vollbackup tib ca 67Min.
3. Vollbackup tib ca 66Min.
-------------------------------------------------------
When I create a custom incremental backup task (1-full-3-in-1, 3-chain), the backup time increases after each additional backup chain. The write speed on an internal hard disk with the backups slows down with the .tibx backup task, the .tib backup task does not have this behavior.
1. full backup tibx about 60min.
2. Full backup tibx ca 88min.
3. Full backup tibx ca 115min.
1. Vollbackup tib ca 61min.
2. Full backup tib about 67min.
3. Full backup tib about 66min.
Attachment | Size |
---|---|
515063-173096.GIF | 275.86 KB |
515063-173098.GIF | 285.7 KB |
- Log in to post comments

So I see your issue is with an internal disk not external. I reconfigured the task to point to an internal disk on my PC and ran another set of 1-3-1-3-1-3 backups. The results were very similar to the first test except the times got shorter. Screenshot provided below:
- Log in to post comments

Ich denke, das die zu sichernde Datenmenge und die verwendete Kompression im Backuptask dieses Verhalten beeinflussen. Mit weniger Datenmenge bekomme ich auch günstigere Ergebnisse.
------------------------------------------
I think that the amount of data to be saved and the compression used in the backup task influence this behavior. With less data I also get better results.
Attachment | Size |
---|---|
515122-173136.GIF | 273.4 KB |
515122-173139.GIF | 273.87 KB |
- Log in to post comments

Agreed, hardware plays a huge part in performance of backup as does the type and amount of data being backed up. Those are the variables that we have to consider in evaluating performance.
In your posted examples, a large increase in elapsed time for backup creation, I note that total amount of data for the backup increased only slightly yet times increased 2 fold. Might I suggest that this indicates the issue is hardware related? Might I also suggest that data and power cables to the target drives be exchanged for different or newer ones to eliminate this being defective cabling? Might I also suggest that you test your PSU with a load tester to see that voltage remains constant across rails? You would be amazed at how that overlooked issue is at root of a large number of issues reported by computer users.
- Log in to post comments

Dear Gerhard,
I've found your feedback with logs and asked the RnD to review them. No update yet, I'll get back with results after my colleagues have finished analyzing the data.
- Log in to post comments


G. Uphoff wrote:Ich habe neue Daten über Feedback hochgeladen.
Thank you! I'll pass the new info to the developers
- Log in to post comments

Same behavior for me. I am backing up 1.9 TB to an external WD hard drive with a USB 3 connection. First full backup is 4 hours which was consistent with ATI 2019. Second full backup was 12 hours. Third full backup was predicted to be 18-20 hours but I cancelled that backup.
I created a new backup and did an initial full backup which took 4 hours. Something is definitely not right for subsequent full backups with ATI 2020. I never saw this behavior with ATI 2019.
- Log in to post comments

Greg, if you have not already done so, pleas sent in-App feedback. Please include the URL for this forum topic to assist tech support in solving the problem.
Thanks
Ian
- Log in to post comments

Thanks Ian. I created a support request as you suggested.
Greg
- Log in to post comments

Is there an update on this issue? A new update was released, and nothing has changed regarding subsequent full backups being significantly slower than the first in incremental chains. Its been over two months...
- Log in to post comments

Dar Wunder wrote:Is there an update on this issue? A new update was released, and nothing has changed regarding subsequent full backups being significantly slower than the first in incremental chains. Its been over two months...
Please create a ticket with Ati so that you will be informed personally about the stand.
Erstelle bitte ein Ticket bei Ati damit Du persönlich über den Stand informiert wirst.
- Log in to post comments

(ATI 2020 Build 22510) Wenn ich einen Benutzerdefinierten inkrementellen Backuptask (1Voll-3Ink-1Voll, 3 Ketten) erstelle, wird nach jeder zusätzlichen Backupkette die Backupdauer erhöht. Die Schreibgeschwindigkeit auf einer externen Festplatte mit den Backups wird mit dem .tibx Backuptask immer langsamer.
Kann es sein, das beim Validieren jetzt nur noch die aktuelle Backupkette validiert wird? (Die Validierungsdauer kommt mir für .tibx sehr kurz vor)
1. Vollbackup tibx ca 51 Min.
Validieren ca 83 Min.
2. Vollbackup tibx ca 125 Min.
Validieren ca 117 Min.
3. Vollbackup tibx ca 169 Min.
Validieren ca 197 Min.
----------------------------------------------------------
(ATI 2020 Build 22510) When I create a custom incremental backup task (1-full-3-in-1, 3-chain), the backup time increases after each additional backup chain. The write speed on an external hard disk with the backups is getting slower with the .tibx backup task.
Can it be validated that now only the current backup chain is validated? (The validation time seems very short for .tibx)
1. full backup tibx about 51 min.
Validate about 83 min.
2. Full backup tibx ca 125 min.
Validate about 117 min.
3. Full backup tibx about 169 min.
Validate about 197 min.
Attachment | Size |
---|---|
521541-176780.GIF | 249.33 KB |
521541-176782.GIF | 240.78 KB |
- Log in to post comments

I'm not sure whether I have the exact same issue or not, but it seems possible.
I use ATI 2020 build 22510, and take an image backup of my NVMe SSD to an USB 3.0 HDD. (And a cloud file backup that is working great.)
The first full image backups took 35-43 minutes (~380 GB of data). I then reconfigured to use 1 full and 9 incremental backups.
The exact scheme is "Custom scheme" then method "Incremental":
Create only a full version after every 9 incremental backups
Old version cleanup rules: store no more than 2 recent version chains
The incremental backups consistently take 5-11 minutes, which is great. The full backups however vary greatly in time taken and are overall very slow. The disk is under heavy load for hours, which is annoying both for noise reasons and because it feels I'm wearing the drive out with constant seeking for hours :-)
After reconfiguring to the 1+9 scheme, the full backups have taken (in chronological order, oldest first):
38m
46m
1h 12m
1h 29m
1h 53m
3h 23m
2h 57m
5h 38m
1h 33m
2h 29m
5h 18m
2h 13m
3h 53m
6h 13m(!) just now; I waited for 2 hours so it could finish before I posted this.
All with roughly the same amount of data, 360-400 GB. The external disk is used exclusively for backups, so no other software will be using it.
Looking at Process Monitor, only about 3.4% of the backup_worker events are WriteFile; the rest are ReadFile.
- Log in to post comments

Hallo Thomas Backman,
Ich denke, das man mit .tib Backup-Archiven deutlich bessere Ergebnisse erzielt bei über 200 GB zu sichernde Datenmenge.
Bei ATI 2020 werden bei Laufwerksbackups nur noch .tibx Archive erstellt.
Möchte man die alten .tib Archive haben, muss man, wenn ein neuer Laufwerksbackuptask erstellt wird den Backuptask mit "Backup später" speichern, Acronis Active Protection ausschalten, dann das Backupscript bearbeiten und aus ".tibx" ".tib" machen. Danach kann Acronis Active Protection wieder eingeschaltet werden.
Sollte man die Backups auch validieren wollen, was ich immer mache, ist bei mir die Komprimierungstufe "Normal" die beste Einstelllung für M2 NVMe SSDs. Verkürzt die zum Validieren benötigte Zeit erheblich.
Eine Anleitung zum Erstellen von .tib Laufwerksbackups:
https://forum.acronis.com/comment/510834#comment-510834
Or Steve Smith Tutorial:
https://forum.acronis.com/forum/acronis-true-image-2020-forum/how-creat…
- Log in to post comments