Validation of incremental backup very slow...
Hi Everyone
I have a full backup (235GB of tibs) of a folder that just did a single incremental backup of just 42MB but took so long to vaildate the increment was pointless.
The PC was idle apart from that single (high priority) backup task.
I thought increments were supposed to be so much quicker.
Anything I can do to find out why it took so long or improve it?
Thanks.
B R
Hi Steve
Thanks for replying.
Sorry for not making this clearer.
The first backup was a full backup (split into 8GB segments) and totals 235GB.
The task is set to run weekly. First week is a full backup then 4 increments. Set to save 1 chain. So I get a new full backup each month.
The first incremental backup took so long to vailidate, which I've not had happen on other tasks, that it makes the whole point of an increment worthless.
Maybe I should delete the task and create a new one?
Thanks for your time.
B R
BR, how does validation take here, and how long does the total backup take to complete, including the incremental files? I would expect the times to be similar.
In order to validate, it validated the entire chain (I believe). If it only validated the last incremental, but something before it was corrupt and not validated, you would not be able to recover. Basically, plan to validate the entire backup chain whenever validation is run.
Thanks Bobbo.
I always set my tasks set to validate when the backup is created.
Repeating Steve's question: how long did the full backup take? I would not expect the validation to take longer than the original backup. The addition of up to 4 incr files will add a bit of time, but not much. Is the destination a local drive; a NAS; the cloud?
I've just done some tests on the ATI 2020 beta on validation and have confirmed that it will always validate all chains in the backup. Let's assume it does the same in ATI 2018. So the more chains you keep, the longer validate will take to run.
Thanks for testing that Bruno! I had no idea, but that can explain a lot about validation times and failures (especially when files have been manually deleted, moved or renamed outside of Acronis). The more chains you keep, or the longer a chain is, it is just going to compound the time with the overall amount of .tibs for that specific backup since it's not just validating the current chain!
I'll be submitting feedback about this. I think validation should only default to the most current chain and no more than one chain at a time. But there should be an option to validate old chains, or select multiple chains if you wanted to manually validate all of them. Doesn't make sense (to me) to keep re-validating every singe backup in every single chain, whenever a new piece of a current chain is created.
BrunoC wrote:I've just done some tests on the ATI 2020 beta on validation and have confirmed that it will always validate all chains in the backup. Let's assume it does the same in ATI 2018. So the more chains you keep, the longer validate will take to run.
I think maybe things are not as straightforward as that. Sometimes Validate does not validate all chains.
My case may be an exception to the rule because there was a problem with some of my backups (for a week or so I was backing up 0 bytes). I did a cleanup on most of the null backups and that seems to have reset something in the ATI database. My current list of backups is
The latest full backup took 1 hour 5 minutes. From File Explorer I ran a Validate of the file highlighted above. The validation ran 26 minutes 38 seconds.
A Validation done yesterday from the ATI GUI ran 26 minutes 8 seconds. The log says is was done against file F:\My Backups\Networked Files\Networked Files_inc_b1_s2_v1.tib.
Either the Validation is running far, far faster than the backups or these validations were not going against all 5 backup chains.
Unfortunately, the log mentions only the one file name (and in some ATI 2020 Beta validations, no file name at all) so it's a bit difficult to tell what is actually being done.
Patrick, not seeing your image with the list of backups.
Opps. Pasting an image doesn't work, I guess. Here's an attached file.
Patrick, what does the Recover tab show for available versions that you can recover. As I look at your listing it looks a bit messy.
How'd you manage to get a 4KB Full followed by a 221GB increment?
B32, B33 and B34 chains look OK, but are they still part of the backup task (which looks like it's been restarted)?
B18 is an orphaned incremental.
BrunoC wrote:Patrick, what does the Recover tab show for available versions that you can recover. As I look at your listing it looks a bit messy.
It's difficult to copy the content of the Recovery tab, but it contains entries going back to 7/13. And oh yes, this is more than messy. As I said, I had a problem with the backup; it had suddenly thought I was backing up 0 bytes of data. That went on for a bit over a week.
BrunoC wrote:How'd you manage to get a 4KB Full followed by a 221GB increment?
I had a whole series of 4KB backups. That's apparently the size of a null backup. I deleted all of the 4KB chains, but there was one last one - a full backup that you ask about. I fixed the problem with backup and it found data to backup. And that resulted in a 221GB incr.
BrunoC wrote:B32, B33 and B34 chains look OK, but are they still part of the backup task (which looks like it's been restarted)?
B18 is an orphaned incremental.
I'll get rid of B18. And yes, it looks like when I fixed the backup (or maybe because I cleaned up the empty chains) that the backup task got reset.
By this way, this "problem" that resulted in null backups is a bit beyond my comprehension. This is a Files and Folders backup that backed up almost all the files in a folder on a NAS. It has worked for may months but suddenly decided it had 0 data to backup. Changing it to backup All the files in the folder got it working again. That makes no sense and I'll dig into it some more, but first I wanted to get a few good backups.