Hi All,
I am having a strange issue regarding Bacula 15.0.2 on Windows Clients. Clients
were installed using the Bacula 15.0.2 Binaries from bacula.org.
We noticed that the C:\Program Files\Bacula\working\host-fd.trace file grows
extremely fast every time a backup occurs. Here is an example of what events we
see. These events seem like they are occurring with every directory specified
to include in our fileset for each client:
* This seems to get added to the trace file every time the bacula service
is started:
* qb-fd: compat/compat.cpp:225-0 Enter norm_wchar_win32_path C:\Program
Files\Bacula\working/bacula-fd.9102.state
qb-fd: compat/compat.cpp:371-0 Leave norm_wchar_win32_path=\\?\C:\Program
Files\Bacula\working\bacula-fd.9102.state
* Here's an example after watching a backup occur (using VSS Snapshots) -
file paths redacted:
* s1-fd: compat/compat.cpp:225-876 Enter norm_wchar_win32_path
C:\Program Files\Bacula\working/bacula-fd.9102.state
s1-fd: compat/compat.cpp:371-876 Leave norm_wchar_win32_path=\\?\C:\Program
Files\Bacula\working\bacula-fd.9102.state
s1-fd: compat/compat.cpp:225-877 Enter norm_wchar_win32_path D:/ [redacted]
s1-fd: compat/compat.cpp:371-877 Leave norm_wchar_win32_path=\\?\D:\ [redacted]
s1-fd: compat/compat.cpp:225-877 Enter norm_wchar_win32_path
//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted]
s1-fd: compat/compat.cpp:371-877 Leave
norm_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2280\[redacted]
s1-fd: compat/compat.cpp:1337-877 sizino=8 ino=0
file=//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted]rdev=0
s1-fd: compat/compat.cpp:225-877 Enter norm_wchar_win32_path
//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted]/.DS_Store
s1-fd: compat/compat.cpp:371-877 Leave
norm_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2280\[redacted]\.DS_Store
s1-fd: compat/compat.cpp:1337-877 sizino=8 ino=0
file=//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted]/.DS_Store
rdev=0
s1-fd: compat/compat.cpp:225-877 Enter norm_wchar_win32_path
//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted]
s1-fd: compat/compat.cpp:371-877 Leave
norm_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2280\[redacted]
s1-fd: compat/compat.cpp:1337-877 sizino=8 ino=0
file=//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted] rdev=0
s1-fd: compat/compat.cpp:225-877 Enter norm_wchar_win32_path
//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted]/.DS_Store
s1-fd: compat/compat.cpp:371-877 Leave
norm_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2280\[redacted]\.DS_Store
s1-fd: compat/compat.cpp:1337-877 sizino=8 ino=0
file=//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted]./.DS_Store
rdev=0
s1-fd: compat/compat.cpp:225-877 Enter norm_wchar_win32_path
//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted].pdf
s1-fd: compat/compat.cpp:371-877 Leave
norm_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2280\[redacted].pdf
s1-fd: compat/compat.cpp:1337-877 sizino=8 ino=0
file=//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/[redacted].pdf rdev=0
s1-fd: compat/compat.cpp:225-877 Enter norm_wchar_win32_path
//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280\[redacted].xlsx
s1-fd: compat/compat.cpp:371-877 Leave
norm_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2280\[redacted].xlsx
s1-fd: compat/compat.cpp:1337-877 sizino=8 ino=0
file=//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy2280/....xlsx rdev=0
--
I've already tried disabling debug logging / tracing on the QB client above
(opened bconsole on server and ran 'setdebug level=0 trace=0 client=QB'), but I
still continue to see thousands of these entries display in the trace log when
a backup is run.
The backup job logs themselves do NOT report any errors (they report success,
no skipped files, etc.). I do not see any recurring issues with VSS Shadow Copy
creation ("vssadmin list writers" on client reports all writers are in stable
state, plus job logs indicate snapshot creation is successful).
For an example on size consumption - the s1 host backs up about 15TB of data.
The trace file grew 135GB in approximately 15 days.
Does anyone have any ideas what might be going on - either what these trace
reports mean and/or how I can address or at least stop them from logging so
much?
Thank you!
Derek
Confidentiality Notice: This e-mail is intended only for the use of the party
to which it is addressed and may contain information that is privileged,
confidential or protected by law. If you are not the intended recipient, you
are hereby notified that any dissemination, copying or distribution of this
e-mail or its contents is strictly prohibited. If you have received this
message in error, please notify the sender immediately by replying to the
message and deleting all copies of the message and any attachments from your
computer system.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
