Error while checking the metadata integrity of point in time in the archive
I've been using True Image for years, backing up my various hard disks daily to a big 8 TB drive. Sometimes I open True Image for whatever reason, and it tells me first thing if the last backup is good. Well lately it's been telling me that "Error while checking the metadata integrity of point in time in the archive" and I have no idea what that means other than there is a problem. Anyone know what it means and how to fix it?
Thanks for the link, Steve. Yeah, seems like this issue is reported either when memory is failing, or when using a RAMDISK, or if there is extreme overclocking of memory or CPU.
OC's are fun, and often work across multiple applications without issue once you find the "sweet spot" for stability. But long read/writes processes such as backups, seem to really test the stability of an OC, even where something like Prime95 has run OK.
In the last month, there are probably 3-4 threads on users running into stability issues with backups where the OC was a bit too much, and usually resolved when it was dropped just a little bit.
I am also now getting this error since upgrading (clean install) to windows 10. However I two backups, one of a C partition on one SSD and the other of a D partition on another SSD, both writing to a normal HDD (within the PC). The D partition backups up fine every time. However the C partition works fine twice then gives this error. I reverted the settings back by importing my settings and it does the same thing. Also if I alter any backup in any way (turn off the scheduling or amend the exclusions) it gives the error first time but only on the C partition. Could this be an install corruption? No OC, no memory errors and also have scanned all the HDD's and SSD's.
Darren, if you are 100% sure that you have no hardware type issues with memory, disks, cables etc, then I can only recommend that you open a Support Case direct with Acronis to investigate why you are seeing these PIT's errors. The error itself comes from reading back the data from the .tib file and calculating the checksum for that data / comparing with the value embedded in the .tib file. So any hardware component involved in this process can contribute to the error, hence some users have had a bad memory stick, others have needed to reduce overclocking etc.
Probably will do.. it is just funny how I can recreate it the same every time.... two backups, third fails, re-import settings do it again... I am going to do a thorough test of hardware though just in case.
Man könnte mit dem "MemBench" Tool des "Ryzen DRAM Calculator" den RAM unter Last testen.
Sollte man keine Ryzen CPU verwenden, kann man ein "Custom" Modus mit ca. 75% vom RAM ausgewählt, "Taskscope" 15% (bei alten CPUs), bei weniger als 4 Minuten Laufzeit den "Taskscope" etwas erhöhen, "Stop at" = "Total".
Bei instabilen Einstellungen werden Fehler angezeigt.
Man kann jederzeit mit dem Stop-Button den Test abbrechen.
---------------------------------------
You could test the RAM under load with the "MemBench" tool of the "Ryzen DRAM Calculator".
If you do not use a Ryzen CPU, you can choose a "custom" mode with about 75% of the RAM, "taskscope" 15% (with old CPUs), with less than 4 minutes running time the "taskscope" slightly increase, "stop at" = "Total".
If the settings are unstable, errors will be displayed.
You can always cancel the test with the Stop button.
Daren,
If the task fails... when you say "reimport settings" have you tried to "clone the backup task" to create a new task (using a unique name and letting it run)? If the task is bad, you may just need to start with a fresh one, without importing settings, but "cloning" them so they are identical, but not related to each other in anyway.
I would also definitely do a health check of the source and destination disks (chkdsk /f /r) and perhaps an OS health scan too (sfc /scannow) and make sure there is plenty of space free on both disk. If they are getting below 15%, performance can suffer, especially if the disk has bad sectors.
Had a cloud backup start doing this - I have RAM disk so will disable it and see if that solves the issue. I can ,recover without issue but not run backup task.
problem started a while back, just before heading overseas for 3 weeks only investigated what was happening when I realised problem with the backup - had forgotten about it, another seniors moment.
Ian
Hi all.
This is my first post on this forum. I use ATI 2018. I'm here because I would like to confirm that corrupted RAM can damage your backups. I was struggling with corrupted backup after that I wanted to restore my system partition with backups that have never been validated. I even wasn't aware that all my backups has errors. Terrible matter. Then I started searching infos about error. I get after validation which was " the last backup failed error while checking the metadata integrity"
My computer was getting occasional BSODs etc. which could confirms that my RAM fails. So I started testing RAM with many software. Memtest86+ didn't find any errors (all night test, passed). Finally I found small app that found first error https://hcidesign.com/memtest/
After that I started removing RAM modules from computers and testing them separately (I have 2x 16GB DDR4). One of them was getting error on HCI Memtest , so I changed memory slot. After that all this "bad" module started working fine. RAM seems to be working with no issue right now. I'm not sure where was the problem, my first suspicion is bad inserted RAM module to slot (bad connect).
After that all my backups have passed validation.
It's good info. Check your RAM when your backups do not validate.
All the best
Lukas
Lukas, welcome to these public User Forums.
Finding bad RAM modules can be tricky but if not done can cause all sorts of issues, so well done for identifying your problem module and replacing it.
Thanks for sharing the link to the memtest utility that worked for you!