Restoring image - lots of inactive time

[YesAndNo]

This is a long shot as it there are probably a lot of variables as to what the problem is but here it is anyway.

Restoring an image takes ages. a 40GiB images restored as 'raw' (it is a veracrypt encrypted partition) restores about 500MB then waits with no actively for maybe a couple of minutes. This happens maybe 3 times then a longer burst of actively then stop for some minutes, then more short bursts etc. I think it took about 40 minutes to restore the 40GiB partition.

This has happened for a while now when restoring but I'm only bringing it up now as I updated to latest IFW and because the restore was to a different drive and it still happened.

The restore is done from TBWinPE, so minimal other interference to blame.

Any ideas? I've tried enabling the "unmap / trim..." checkbox with no improvement but that's about all.

Thanks for any help.

[TeraByte Support(PP)]

You don't say what the source drive is. Does a verify of the backup image run at normal speed (no problems reading from that drive)? If USB drives are involved, I have noticed at times that the first connect doesn't always connect at full speed and a reconnect is necessary.

Is it any different if a non-raw (normal) partition image is restored to the same destination?

If the restore is possible in Windows you could try from there. Also, you could try IFL. Possibly the TBWinPE environment isn't seeing the drive or interface correctly or at full speed. Might be drivers if Windows and IFL are fast.

[TeraByte Support]

If one drive is much faster than the other you may see pauses so one drive seems like it was slow, either the bus or drive. If you're using USB2 it's going to be much slower than the internal drive and about 1g per IIRC. The other issue is if the drive internally is having issues, but is able to recover which takes time.

[YesAndNo]

Sorry I didn't reply straight away.

After posting this I had an idea what it might be (often the way). I think it's to do with having lots of Incremental backups. I restored the last full backup to check and it worked straight through with no problem.

I use Tom Cole's backup scripts via TBWinPE and have been for years so don't really want to change to image for Linux even though I've used Linux as my main OS for several years.

I'm wondering if 'changes only' backups would work better. I can't remember why I chose incremental over changes-only now but there was a reason at the time.

I haven't tried the other things you mention here but will when I do my next backup in a few days.

I don't think Tom's scripts have an option for setting the maximum number of incremental backups before reverting to full, otherwise I'd try that.

Thanks for helping.

[Bob Coleman]

Choosing changes only instead of incremental doesn't completely make sense. The only relevant choices when creating a backup are "Full" and "Changes Only".

Something created as "Changes Only" may ultimately be differential or incremental depending on how the base for the changes only is chosen.

Perhaps you understand all this and should have characterized the choice as differenhtal vs. incremental.

If you don't understand my point, post back and I'll elaborate.

[OldNavyGuy]

Excerpts from the IFW User's Guide (pages 235 - 237)...

Incremental -

Incremental backups include only data that has changed since the most recent
backup was performed—whether the most recent backup was a full backup or a
previous incremental backup

Differential -

Differential backups include only data that has changed since the most recent full
backup was performed

By its nature, the size of a differential backup grows over time. If you wait long
enough between full backups, your differential backup could become almost as
large as a full backup, and take almost as much time to create.

[TAC109]

I don't think Tom's scripts have an option for setting the maximum number of incremental backups before reverting to full, otherwise I'd try that.

Hi YesAndNo

Using my scripts you can limit the number of Change-only backups per Full backup by using the 'set rb1' run-before entry in the IFW_Env.cmd file. The value is currently set to 30 but you can reduce this down to suit your circumstances.

Hope this helps

[Bob Coleman]

Yes, so according to that definition, the first changes only backup after a full backup could be considered to be incremental, differential or both. I think I understand the concept here, but it can be confusing.

Excerpts from the IFW User's Guide (pages 235 - 237)...

Incremental -

Incremental backups include only data that has changed since the most recent
backup was performed—whether the most recent backup was a full backup or a
previous incremental backup

Differential -

Differential backups include only data that has changed since the most recent full
backup was performed

By its nature, the size of a differential backup grows over time. If you wait long
enough between full backups, your differential backup could become almost as
large as a full backup, and take almost as much time to create.

[YesAndNo]

Thanks for the replies and help everyone.
Yes, I was getting my terms wrong, I meant differential and incremental. not 'changes only' and incremental.

Tom, thanks, I either didn't notice that option in the IFW_Env.cmd file, or maybe I did but didn't fully get it at first.
If I understand from the description correctly, %nco% returns the number or previous incremental/differential backups and if greater than or equal to 30 by default, will return 54321 to rb1 and force a full backup. If I wanted to change that to, say, 10, I assume I'd copy or un-comment the line like this:

(set rb1= if %%nco%% geq 10 exit/b 54321 ^& rem Maximum of 30 Chngs/Full)

If you get a chance to confirm that, that would be great before I change all my scripts.
Thanks a lot.

[TAC109]

Yes, that is the correct change.

You could also look at 'set ra0' if you desired. It’s purpose is to flag a warning if the next backup will be a 'full'. You would change the 29 to 9. However this entry is entirely optional, depending on your requirements.

Cheers