IFW: Exclude (/exlist) seems to ignore this

[rseiler]

I've been using /exlist for years, and it's worked. I'm aware of some of the tricky aspects of it, as explained in the manual.

However, the latest addition to my exclusion text file seems to be ignored. It's no different (except for the directory, which is definitely correct) than any of the others in the file. It looks like the example from the manual:

[k]\Outlook Archives\ >

Yet, when I look in the log file, I see the usual "Warning: Data excluded from files based on list" message followed only by my older five exclusions (they've been there a while), not the new one.

At first, I thought there might be a limit of 5 items in the exclusion file, but that seems not to be the case. Then I thought the file might need (or not want) a blank line at the end to catch the last item in the file, but that doesn't seem to be the case either. And it doesn't have a problem with a two-word folder name, since one of my others has three.

The weirdest thing was when I moved the new entry up in the list, so it was no longer the last item, and it was still ignored.

And it really is ignored, the log is right: I extracted the contents of the excluded folder with TBIView and verified that the files were actual PST files that open in Outlook (plus, the image was MUCH larger than it should have been).

The manual says "Excluded files extracted from the image using TBIView or TBIMount will be full of zeros. An exception to this are very small files on NTFS (the contents of those files will be intact)."

This is NTFS. Is there possibly another exception to this: large Outlook PST files? Or is there some other explanation that I'm missing?

I've been using 2.97 releases (currently "e"). I don't know if the above happens with earlier releases. It's Server 2003R2, and the above is run from a batch.

[TeraByte Support]

if you're doing a differential/incremental it will use whatever is in the
base.

"rseiler" wrote in message news:10231@public.image...

I've been using /exlist for years, and it's worked. I'm aware of some of the
tricky aspects of it, as explained in the manual.

However, the latest addition to my exclusion text file seems to be ignored.
It's no different (except for the directory, which is definitely correct)
than any of the others in the file. It looks like the example from the
manual:

[k]\Outlook Archives\ >

Yet, when I look in the log file, I see the usual "Warning: Data excluded
from files based on list" message followed only by my older five exclusions
(they've been there a while), not the new one.

At first, I thought there might be a limit of 5 items in the exclusion file,
but that seems not to be the case. Then I thought the file might need (or
not want) a blank line at the end to catch the last item in the file, but
that doesn't seem to be the case either. And it doesn't have a problem with
a two-word folder name, since one of my others has three.

The weirdest thing was when I moved the new entry up in the list, so it was
no longer the last item, and it was still ignored.

And it really is ignored, the log is right: I extracted the contents of the
excluded folder with TBIView and verified that the files were actual PST
files that open in Outlook (plus, the image was MUCH larger than it should
have been).

The manual says "Excluded files extracted from the image using TBIView or
TBIMount will be full of zeros. An exception to this are very small files on
NTFS (the contents of those files will be intact)."

This is NTFS. Is there possibly another exception to this: large Outlook PST
files? Or is there some other explanation that I'm missing?

I've been using 2.97 releases (currently "e"). I don't know if the above
happens with earlier releases. It's Server 2003R2, and the above is run from
a batch.

[rseiler]

I checked, and they're not in the base. They're new since after the time that the base was made.

One correction from earlier: They're ZIPs of PST files, not PST files.

[TeraByte Support]

In other words, it needs to be on the full backup. Check that and that it's
pulling the file you expect.


"rseiler" wrote in message news:10237@public.image...

I checked, and they're not in the base. They're new since after the time
that the base was made.

One correction from earlier: They're ZIPs of PST files, not PST files.

[rseiler]

Apologies that I'm probably still not following you (I swear that English is my first language).

It sounds now like you might be referring to /exlist also needing to be used when making the full backup, which it is (and it points to the same file as the differential uses).

However, this new exclusion came after the last full backup, so maybe what you're saying is that exclusions only work if they match what was originally excluded in the full? If so, that would explain it.

[TeraByte Support]

the incremental/differential pulls forward the exlist from the full, not the
file.

"rseiler" wrote in message news:10240@public.image...

Apologies that I'm probably still not following you (I swear that English is
my first language).

It sounds now like you might be referring to /exlist also needing to be used
when making the full backup, which it is (and it points to the same file as
the differential uses).

However, this new exclusion came after the last full backup, so maybe what
you're saying is that exclusions only work if they match what was originally
excluded in the full? If so, that would explain it.

[rseiler]

Got it. I completely missed that angle somehow. Thanks.