|
Hello, Bacula Users. I apologize for adding
yet another thread to this topic. I've seen a number of threads that make
mention of these Vista problems, and they seem to drop off sometime around
mid-2007. Yet, for me the issues persist, so I'm perplexed. If
someone has a link to the definitive answer(s) to these issues, I'd appreciate
your reply.
For the client in question, I am using Backula
version 2.4.2 on Vista Ultimate 64-bit. I've been using Bacula for a while now, and have come to enjoy its
reliability and configurability. Unfortunately, I'm in an environment
where I must also support Windows, including Microsoft's latest proof that they
don't understand upward compatibility: Vista. Bacula seems to handle the
various Linux flavors in the network, and even the XP client seems quite
reliable. However, with Vista (especially Vista 64-bit) we are seeing a
significant set of problems.
The most costly issue (for me) is the monkey wrench
that I started to see surface in this forum about a year and a half ago, where
the "junctions" (provided by M$ to point directories to legacy directory names)
cause the FD to bail out with messages like:
27-Oct 02:05 m1330-fd JobId 414: Could not
open directory c:/Users/dennis/AppData/Local/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data: ERR=The name of the file cannot be
resolved by the system.
Not long after this message began to appear on
internet, I saw a message (22-Jun-2007) from Kern Sibbald saying that the
problem should be solved with a few lines of code. I've not found much of
consequence on this topic in the sixteen months since that time, but the problem
persists (at least for me). Have I missed some key version of the
software, or pointer designed to help get past this error? (It is a big
deal in spite of the following observation by Mr. Sibbald: "However, if I am not mistaken, it *is* backing up
these junctions, and will probably restore
them correctly...") For me, my backups fail consistently with the
following:
27-Oct 02:17 m1330-fd JobId 414: Fatal error: Too
many errors.
27-Oct 02:17 luke-sd JobId 414: Job write elapsed time =
00:11:54, Transfer rate = 7.516 M
bytes/second
By the way, exclusions do not seem to help resolve
this (or maybe I don't know the proper trick). I have the following in my
fileset, but to no avail:
FileSet {
Name =
"VistaSet"
Enable VSS = yes
Include {
Options {
WildDir = "c:/Users/*/Application
Data/Application Data"
<snip>
Exclude =
Yes
}
File =
"c:/Users/dennis/AppData/"
File =
"c:/pers-data/"
<snip>
Options
{
signature =
MD5
compression =
GZIP
_onefs_ =
no
}
}
}
In spite of this exclusion, I still receive
(thousands of) messages like the example from
above.
- - - - - - - - - - - -
The other issue is VSS. I've seen threads
that indicate this issue was solved long ago (cannot find an example at the
moment though - sorry)... but the most recent mention I find of this is from
August 8 this year, when Kern Sibbald indicated that a new build was ready - but
then the trail runs cold. Is there any hope of regaining VSS support on
64-bit Vista?
Thank you for your time!!!
Dennis
| 