incremental takes as long as Full
I increased the data on the source drive by 5%, and the Incremental took as long as a Full.
About 9 hours including Verify, after I copied 35GB of small files to a HDD that thus increased from 705GB to 740GB.
The source drive isn't a system drive, but I always use Drive backup (since one can get files off, I figure why not, that way I can restore with ATI boot media). I never defrag between a Full and it's Incremental. The PC was doing nothing else. All both HDDs are 2TB internal SATA. The backup target HDD is 100% dedicated to that function.
Any advice, please?
Thank you very much for your reply, Steve!
To be honest I aborted it after a few hours, and ran a Full the next night instead.
Next time I have such an issue I'll try out the MVP Log Viewer. That was the first Incremental I'd done on this job; hopefully it doesn't always happen (I'd rather not run such a long backup daily).
I recall noticed a few discussions others with this issue, so great to know there isn't some known concern.
In reply to Thank you very much for your… by truwrikodrorow…
You say that this was the first incremental. If this was the first time that backup task had run, then that incremental task began with a full backup. All incremental and differential backup tasks begin with a full backup.
Sorry tuttle, I should have been more clear that I had run a Full before this Incremental.
Still not clear. Did you run the same backup task previously?
Yes, I had run the same backup task previously.
I did understand that the first time a task runs it is a Full. So the 2nd time was, as I said, an Incremental.
Yes, I had run the same backup task previously.
I did understand that the first time a task runs it is a Full. So the 2nd time was, as I said, an Incremental.
First New question: during the Validation step after an Incremental image is created, does only that Incremental get validated, or does the whole chain (of Full and Incrementals) get validated?
Last night I ran the first Incremental on the Full done the previous day. In the 24 hours between jobs, there was close to zero NET change to the 744GB on the backup source drive.
However, FWIW, I have been (maybe I should stop) using this non-system HDD (that, again, is the source drive) as the temporary download destination for my Usenet News client. Which means that typically five to fifty GB of rar files are downloaded to it during the day...but just temporarily, until they are UN-rared onto a drive not involved in the backup. So...
Second New question: Is backup/validation time going to be significantly impacted by files that before an Incremental temporarily, but no longer, remain on the source drive? (If the answer is yes, I guess I should start using a HDD not involved in an ATI backup job for this (temporary download destination for my Usenet News client) function.
I'm guessing backup time itself isn't, because the Incremental (for the day there was close to zero net change) is only 50MB (sweet; that's essentially nothing, and I did read somewhere that the file itself has a little overhead).
Here's my log for the job (thank you to Steve for helping me (on another thread) get the wonderful MVP Log Viewer 1.24:
|
2017-08-10 16:59:11:685 7232 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false; Start: 8/10/2017 4:59:11 PM |
One minute for the backup is sweet. Three hours for the validation...not so sweet, but I guess if I must I'll live with that. And can understand that, if it's validating the whole chain and not just THAT Incremental.
Coyote, as far as I am aware, validation is always for the whole backup version chain, not just an individual image file.
With regards to your temporary Usenet files, you should exclude the folder(s) that hold these from your backup task to ensure they have no impact on the backup activity.
Validation is unrelated to the actual files on your source disk drive as far as I understand, as it is possible to validate any backup image regardless of whether that image was from the same computer or from a different one. Validation recalculates the checksum for the file(s) in the backup version chain and then compares this to the checksum value(s) stored within the image files themselves.
In reply to Coyote, as far as I am aware… by truwrikodrorow…
Thank you very much for your help once again, Steve! Honestly, nothing on my computer is more important, and more important for me to understand, than my backup solution.
While it makes for a lot of validation processing time, I guess it's GOOD that my entire chains are being validated. And another reason to not make one's chains too long.
Great suggestion, Steve, I should have thought to exclude my temporary Usenet folder (actually that folder was containing other stuff too, but I've separated that other stuff out now, so), now it's done.