A little oversight on my bacula-dir.conf example:
I do have the example exclusion that I included in my post, but a quick look
will reveal that it won't help in the example instance. Here's my entire
exclusion set from my VistaSet fileset:
Options {
WildDir = "c:/QuickenW/*/backu*"
WildDir = "[a-zA-Z]:/tmp"
WildDir = "[a-zA-Z]:/temp"
WildDir = "[a-zA-Z]:/System Volume Information"
WildDir = "c:/Windows"
WildDir = "c:/Users/dennis/Local Settings/Microsoft/Windows/Temp*"
WildDir = "c:/Users/dennis/Local Settings/Tem*
WildDir = "c:/Users/All Users"
WildDir = "c:/Users/*/Application Data/Application Data"
WildDir = "c:/Users/*/AppData/Local/Application Data"
WildFile = "[a-zA-Z]:/hiberfile.sys"
WildFile = "[a-zA-Z]:/pagefile.sys"
WildFile = "[a-zA-Z]:/Users/*/AppData/Local/Microsoft/Outlook/*.oab"
WildFile = "[a-zA-Z]:/Users/*/Local*/Applicat*/Microsoft/Outlook/*.oab"
WildDir = "c:/DRIVERS"
exclude = yes
}
----- Original Message -----
From: Bacula User
To: bacula-users@lists.sourceforge.net
Sent: Monday, October 27, 2008 3:59 PM
Subject: Vista 64 - Bacula 2.4.2, VSS and symlink/junction issues
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-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
