Skip to main content

[WORKAROUND] Acronis backups in a loop / data stream error out of a sudden

Thread needs solution

ATIH b6027

The new year is just here and I have another strange bug with ATIH.

nothing has changed (of what I am aware of) since December, hence Acronis fails to backup and now is backing up in a loop, spamming my backup target even though the rule says it should not create more than 2 backups at all.

so we have several problems here:

1. unexplainable stream problem

2. ATIH does not care for settings when this error occours

3. It does not stop itself to backup in case of an error but repeatingly runs the scheduled backup over and over again.

I am getting really sick about this. If I had more time, I would more likely and literally bombard the customer support with all these recent issues that I really do not understand why they happen at all. :(

Is there any way to use the ATIH customer support and skipping the first level procedures?

At the moment I have 27 unsolved problems with ATIH according to my trackings. At least 3 of them are critical means they are render the product either useless or harming its functionality.
 

Instead of recreating my backup job, I rather would like to investigate why this problem occours out of a sudden and why a recreation of the job itself is recommended to solve it.

Attachment Size
acronissystemreport.zip 6.8 MB
error_message.png 62.97 KB
settings.png 63 KB
loop.png 159.47 KB
files.png 87.29 KB
0 Users found this helpful

"Chkdsk" wurde im Überprüfungsmodus für eine Volumemomentaufnahme ausgeführt.  

Dateisystem auf C: wird überprüft.
Die Volumebezeichnung lautet Windows 10 pro x64 UEFI.

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x5 ist
von 0x1183 an für möglicherweise 0x2 Cluster quer verbunden.
    Es wurde eine fehlerhafte Basisdateistruktur für "\Windows\Temp\KARLS-PC-20160102-2307.log <0x10d,0x667f>" gefunden.
        ...online repariert.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x1181 an für möglicherweise 0x1 Cluster quer verbunden.
    Es wurde eine fehlerhafte Basisdateistruktur für "\ProgramData\NVIDIA Corporation\nvstlink.log <0x8,0x11915>" gefunden.
        ...online repariert.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x4 ist
von 0x1182 an für möglicherweise 0x1 Cluster quer verbunden.
    Es wurde eine fehlerhafte Basisdateistruktur für "\Users\Karl\AppData\Local\Mozilla\Firefox\Profiles\j3wuvf7s.default\cache2\entries\B6AE1E2498CFC3D07A69AAD95D9D5846AF40EAFD <0xa,0x124c1>" gefunden.
        ...online repariert.
    Datei "\Users\Karl\AppData\Local\Mozilla\Firefox\Profiles\j3wuvf7s.default\cache2\entries\032B05841BAFDF44051892953F634C7FDDD20E61 <0x63,0xe3>" und Datei "\ProgramData\NVIDIA Corporation\nvstlink.log <0x8,0x11915>" besitzen jeweils das logische Cluster "0x1181".
        ...in der Warteschlage für die Offlinereparatur platziert.
    Datei "\Users\Karl\AppData\Local\Mozilla\Firefox\Profiles\j3wuvf7s.default\cache2\entries\88079CD7CADCBFCFBBBCE8CAA5A86B2043E5C5C5 <0x122,0x3fe>" und Datei "\Users\Karl\AppData\Local\Mozilla\Firefox\Profiles\j3wuvf7s.default\cache2\entries\B6AE1E2498CFC3D07A69AAD95D9D5846AF40EAFD <0xa,0x124c1>" besitzen jeweils das logische Cluster "0x1182".
        ...in der Warteschlage für die Offlinereparatur platziert.
    Datei "\ProgramData\Microsoft\Windows Defender\Scans\MetaStore\1\73\DD1ED0260891BA75.dat <0xeb,0x1baa>" und Datei "\Windows\Temp\KARLS-PC-20160102-2307.log <0x10d,0x667f>" besitzen jeweils das logische Cluster "0x1183".
        ...in der Warteschlage für die Offlinereparatur platziert.
                                                                                       
  416768 Datensätze verarbeitet.                                                          Dateiüberprüfung beendet.
                                                                                       
  4901 große Datensätze verarbeitet.                                                                                                                           
  0 ungültige Datensätze verarbeitet.                                
Phase 2: Die Dateinamenverknüpfung wird untersucht...
                                                                                       
  482546 Indexeinträge verarbeitet.                                                       Indexüberprüfung beendet.
                                                                                            Die verlorene Datei "\ProgramData\Microsoft\Crypto\RSA\MachineKeys\3948019f2368d19cd6e2ebdb4d328c30_266645a5-11b7-4807-8af1-70db7087061b <0x59,0xce99>" wurde gefunden. Eine erneute Verbindung mit Index "$I30" von Verzeichnis "\ProgramData\Microsoft\Crypto\RSA\MachineKeys <0x42,0x2081e>" wird angefordert.
        ...online repariert.
                                                                                        
Phase 3: Sicherheitsbeschreibungen werden untersucht...
    Es wurde ein beschädigter Sicherheitsbeschreibungseintrag gefunden an Offset 0x6af890 in \$Secure <0,0x9>:$SDS.
        ...in der Warteschlage für die Offlinereparatur platziert.
    Es wurde ein beschädigter Sicherheitsbeschreibungseintrag gefunden an Offset 0x6b3fb0 in \$Secure <0,0x9>:$SDS.
        ...in der Warteschlage für die Offlinereparatur platziert.
    Es wurde ein beschädigter Sicherheitsbeschreibungseintrag gefunden an Offset 0x680000 in \$Secure <0,0x9>:$SDS.
        ...in der Warteschlage für die Offlinereparatur platziert.
Überprüfung der Sicherheitsbeschreibungen beendet.
                                                                                       
  32893 Datendateien verarbeitet.                                        CHKDSK überprüft USN-Journal...
Die Überprüfung von USN-Journal ist abgeschlossen.
Es wurden Probleme erkannt. Einige davon wurden online behoben.
Die verbleibenden Probleme müssen offline behoben werden.
Führen Sie "chkdsk /spotfix" zum Beheben der Probleme aus.

 243192828 KB Speicherplatz auf dem Datenträger insgesamt
  61355776 KB in 152130 Dateien
    106292 KB in 32891 Indizes
    498008 KB vom System benutzt
     65536 KB von der Protokolldatei belegt
 181232752 KB auf dem Datenträger verfügbar

      4096 Bytes in jeder Zuordnungseinheit
  60798207 Zuordnungseinheiten auf dem Datenträger insgesamt
  45308188 Zuordnungseinheiten auf dem Datenträger verfügbar

----------------------------------------------------------------------

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x5
in der Datei 0x667f belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (0x80, "") wird
vom Datensatzsegment 0x667F gelöscht.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x11915 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (0x80, "") wird
vom Datensatzsegment 0x11915 gelöscht.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x4
in der Datei 0x124c1 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (0x80, "") wird
vom Datensatzsegment 0x124C1 gelöscht.

Phase 2: Die Dateinamenverknüpfung wird untersucht...
CHKDSK überprüft nicht indizierte Dateien, um die Verbindung mit dem ursprünglichen Verzeichnis wiederherzustellen.
Verwaiste Datei 394801~1 (52889) wird in Verzeichnisdatei 133150 wiederhergestellt.
Verwaiste Datei 3948019f2368d19cd6e2ebdb4d328c30_266645a5-11b7-4807-8af1-70db7087061b (52889) wird in Verzeichnisdatei 133150 wiederhergestellt.
Verwaiste Datei 394801~1 (52889) wird in Verzeichnisdatei 133150 wiederhergestellt.
Verwaiste Datei 3948019f2368d19cd6e2ebdb4d328c30_266645a5-11b7-4807-8af1-70db7087061b (52889) wird in Verzeichnisdatei 133150 wiederhergestellt.
  1 nicht indizierte Dateien im ursprünglichen Verz. wiederhergestellt.

Phase 3: Sicherheitsbeschreibungen werden untersucht...
Ein Indexeintrag mit der Kennung 11623 wird in Index $SDH der Datei 9 eingefügt.
Ein Indexeintrag mit der Kennung 11691 wird in Index $SDH der Datei 9 eingefügt.
Segment des Sicherheitsdatensatzes wird repariert.
Attribut DATA wird in Datei 26239 eingefügt.
Attribut DATA wird in Datei 71957 eingefügt.
Attribut DATA wird in Datei 74945 eingefügt.

 

possibly the cause... I will repair this and see if the problem persists. Again this reinforces me that ATIH should run a chkdsk prior a backup / restore on all source and target partitions...

 

ran chkdsk but it did not solve the problem.

I have now created a new backup job and this one works fine.

I haven't deleted the old one in case anyone wants to investigate why the old job itself seems to be corrupted.

okay I think I found the reason, but I am not yet sure if this is reproducible. If I rename the backup job the problem will occour. As posted in #3 I created a new job this job was okay, I renamed it (previous name was an automatic name based on the drive's name) and the problem came back.

 

I am feeling so helpless now even creating new jobs without renaming wont help. Acronis keeps backing up in a loop because of this data stream error that happens after validation... :((

I've found all versions of Acronis from 2013 on forward, seem to get corrupted at some point in time. It's not just Acronis though, the same happens in CrashPlan, Retrospect and other backup software I've tried.  Doesn't make me feel any better about any of them, but that's just what I've found over time.

Honestly, I don't trust any of the applications 100% to just set and forget backups so I typcially do an offline full system image as often as I feel it's necessary to preserve my OS or other precious data.  

I also don't validate my backups (I know sounds dumb, but I do technically validate them on my own).  Instead of using the Acrnis validation option, I simply double click the TIBS and navigate through them after the backup has been created.  If you can navigate, you're good to go.  If it throws and error tying to navigate with explorer, your backup is corrupt.  

I also don't use Disk Director so don't know if it's a bug by having both installed or not.  Where did you get Acronis True Image 2016 vs 6029?  I only see 6027 as of 12Dec2015.  I'm on 2015 and it is version 6613 - are you on something else?

My recommendation, although doesn't solve the problem as to why this is happening in the first place, is to stip out all Acronis products (run the clean up tools after you manually delete them).  Then run CCleaner a few times until everything comes up clean, reboot, run CCleaner a few more times, reboot and install Acronis from scratch.  It is a real pain, but usually this gets me working again and tends to keep things running smooth for a long time (until the next Acronis update or release anyway). 

Sorry I can't provide more info about the cause of the problem or how to actually fix it/then.  I can only offer some suggestions based on my own past experiences thta might at least get things working correctly again.  

Hi Bobbo, that was a typo, my version is of course 6027.

I still face this issue here and wasn't able to any single backup ony my computer since then.

As I did not get any response here I finally decided to uninstall ATIH 2016 and cleanup all Acronis orphans in ProgramData %Apadata% and Program Files (x86O) and reinstalled Acronis again.

 

Now a backup is possible again. This all shows me that there was no issue with my hardware or windows but more proably a problem with the Acronis metadata regarding, as the job terminated with the error at the end of every backup and validation.

Hello, Karl!

I had a look at your system report and I've discovered that the Archives database was corrupted. So it's very likely that this was the cause of those errors.

Now, as to why it was corrupted I cannot say for sure. I've tried to reproduce this using several different scenarios, but had no luck.

Thank you Dmitry for looking into this strange problem. I hope it will not come up again and based on my number of ATIH 2016 installations it is infact a rare issue. IF it happens again do you think it makes sense to preserve some files before reinstalling so you could have a look on them?

 

Karl, I would appreciate it if you gathered a new system report if the problem ever happens again, thanks.

Alright Dmitry, I will!