Page 1 of 1
Is this change by design or a bug?
Posted: Fri Jan 11, 2013 10:50 pm
by DrTeeth
I can reproduce this, v2.78.
I have IfW set up with "Speed Up Changes Only Backup" selected and saved as a default. When creating a differential (not incremental) backup, this option *stays* selected and a further hash file is created, in the same format as the full backup's, viz <filename>.#0.
In previous versions, this option cleared automatically when creating diff backups. Is this a bug or by design? If by design, is it to speed up the creation of incremental backups?
Thanks
DrT
Re: Is this change by design or a bug?
Posted: Sat Jan 12, 2013 1:29 am
by TeraByte Support(PP)
Yes, it's now supported with changes only backups to speed up incrementals.
Re: Is this change by design or a bug?
Posted: Sat Jan 12, 2013 1:41 am
by TAC109
I'm pleased you asked this question as I was wondering if hash files
would now be created for 'changes only' files. (I'm still using an old
version of IFW, so haven't been able to try this out.)
Note that there is no difference as far as IFW is concerned between
the first Diff created after a Full, and the first Incr created after
a Full.
Also, it is quite valid to switch from taking Diff images to taking
Incr images, so for example the imaging sequence of Full1, Diff1,
Diff2, Incr1, Incr2, would be quite correct, where each Incr image is
chained to the immediately preceding image. Restoring Incr2 would
follow the path Incr2 -> Incr1 -> Diff2 -> Full1.
Similarly, switching from Incr to Diff should work. i.e. in the
sequence Full5, Incr5, Incr6, Diff5 (where each 'changes' image is
chained to the previous image), Diff6 (chained to Incr6) should be ok.
For the "Speed Up Changes Only Backup" option to work with Incr
images, hash files would need to be created for each 'changes' image,
and would represent the source partition at the time that image was
taken.
On Fri, 11 Jan 2013 14:50:44 PST, DrTeeth wrote:
>I can reproduce this, v2.78.
>
>I have IfW set up with "Speed Up Changes Only Backup" selected and saved as a default. When creating a differential (not incremental) backup, this option *stays* selected and a further hash file is created, in the same format as the full backup's, viz .#0.
>
>In previous versions, this option cleared automatically when creating diff backups. Is this a bug or by design? If by design, is it to speed up the creation of incremental backups?
>
>Thanks
>
>DrT
>
Re: Is this change by design or a bug?
Posted: Sat Jan 12, 2013 3:38 pm
by DrTeeth
TAC109 wrote:
> Note that there is no difference as far as IFW is concerned between
> the first Diff created after a Full, and the first Incr created after
> a Full.
In the the documentation, this point is not clear at all.
> Also, it is quite valid to switch from taking Diff images to taking
> Incr images, so for example the imaging sequence of Full1, Diff1,
> Diff2, Incr1, Incr2, would be quite correct, where each Incr image is
> chained to the immediately preceding image. Restoring Incr2 would
> follow the path Incr2 -> Incr1 -> Diff2 -> Full1.
>
> Similarly, switching from Incr to Diff should work. i.e. in the
> sequence Full5, Incr5, Incr6, Diff5 (where each 'changes' image is
> chained to the previous image), Diff6 (chained to Incr6) should be ok.
I wonder if there is an easy way to tell which changes-only files are differentials or incrementals? It would be very helpful.
Cheers
DrT
Re: Is this change by design or a bug?
Posted: Sat Jan 12, 2013 8:01 pm
by TAC109
On Sat, 12 Jan 2013 07:38:06 PST, DrTeeth wrote:
>TAC109 wrote:
>
>> Note that there is no difference as far as IFW is concerned between
>> the first Diff created after a Full, and the first Incr created after
>> a Full.
>
>In the the documentation, this point is not clear at all.
There is no distinction in IFW between Diff's and Incr's. IFW makes a
Changes backup with the differences between what is actually on the
source disk and what was in the backup image (chain) that was supplied
in the /base parameter.
>[...]
>I wonder if there is an easy way to tell which changes-only files are differentials or incrementals? It would be very helpful.
>
See above.
The distinction between Diff and Incr backups is a human concept.
Perhaps you could include something in the name you give to the image
to make the distinction clear to you?
Re: Is this change by design or a bug?
Posted: Sat Jan 12, 2013 8:53 pm
by mjnelson99
I guess as long as it takes about 35-65 minutes to image and
b-f-b validate, I will do full images every time.
I image to both D partition and SD cards.
If I had a 100 GB partition I probably would do different.
Mary
On 1/12/2013 2:01 PM, Tom Cole wrote:
> On Sat, 12 Jan 2013 07:38:06 PST, DrTeeth wrote:
>
>> TAC109 wrote:
>>
>>> Note that there is no difference as far as IFW is concerned between
>>> the first Diff created after a Full, and the first Incr created after
>>> a Full.
>>
>> In the the documentation, this point is not clear at all.
>
> There is no distinction in IFW between Diff's and Incr's. IFW makes a
> Changes backup with the differences between what is actually on the
> source disk and what was in the backup image (chain) that was supplied
> in the /base parameter.
>> [...]
>> I wonder if there is an easy way to tell which changes-only files are differentials or incrementals? It would be very helpful.
>>
> See above.
> The distinction between Diff and Incr backups is a human concept.
> Perhaps you could include something in the name you give to the image
> to make the distinction clear to you?
>
>
Re: Is this change by design or a bug?
Posted: Sun Jan 13, 2013 1:16 pm
by DrTeeth
On Sat, 12 Jan 2013 12:01:13 PST, just as I was about to take a herb,
Tom Cole disturbed my reverie and
wrote:
>Perhaps you could include something in the name you give to the image
>to make the distinction clear to you?
Yes. If I have an old set of backup files and wish to delete some, I
would need to know which files rely on which to have a slim and
functional backup set.
--
Cheers
DrT
______________________________
We may not be able to prevent the stormy times in
our lives; but we can always choose whether or not
to dance in the puddles (Jewish proverb).