Erik P. Olsen wrote: > On 03/04/09 21:19, Kevin Keane wrote: > >> Erik P. Olsen wrote: >> >>> On 03/04/09 18:56, Kevin Keane wrote: >>> >>> >>>> Foo wrote: >>>> >>>> >>>>> On Thu, 02 Apr 2009 17:57:32 +0200, John Drescher >>>>> <dresche...@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>>> On Thu, Apr 2, 2009 at 11:27 AM, Kevin Keane >>>>>> <subscript...@kkeane.com> wrote: >>>>>> >>>>>> >>>>>>> This actually is correct behavior. If you look carefully, you will >>>>>>> see >>>>>>> that these two directories are actually not directories at all, but >>>>>>> rather junction points that simply reference other directories >>>>>>> somewhere >>>>>>> else. Windows junction points are like a cross between Linux symlinks >>>>>>> and Linux mounts. >>>>>>> >>>>>>> >>>>>>> >>>>>> I would like to add to the OP that these should be ignored as they >>>>>> are harmless. >>>>>> >>>>>> >>>>> They belong to .net 2.0 and can be included explicitly. If you >>>>> don't, I would expect .net to break in some mysterious way, >>>>> although it might break anyway if Bacula cannot restore junction >>>>> points (can it?). At least I include them to be sure. You'll get >>>>> warnings about them anyway if you include the whole partition, but >>>>> that can be ignored. >>>>> >>>>> I guess if the restore doesn't work properly, you can always >>>>> reinstall ..net (+ hotfixes/service packs) to fix it, though that's >>>>> not ideal. Thankfully I didn't run into this so far. >>>>> >>>>> >>>> Actually, you probably should *not* include these directories >>>> explicitly. Because they are junction points, the actual data is >>>> stored somewhere else, usually on the same file system, and already >>>> is getting backed up. By including the directories explicitly, you >>>> would basically on restore create a real directory instead of a >>>> junction point, which could wreak havoc with .NET updates in the >>>> future (as well as many other issues, I'm sure). >>>> >>>> >>>> >>> I think it would be wiser if the client instead of backing-up a >>> junction point rather would back-up >>> the actual data. It is not easy to find all junction points and treat >>> them manually. I for one would >>> not be able to perform this task, IMHO it should be done automagically >>> by the client. It would also >>> be perfect if a junction point would be recreated as part of a restore >>> operation. >>> >>> >> The data is backed up automatically from the location where it really >> resides (as long as the file set includes that location, of course. >> Usually, not a problem because most of these types of junction points >> simply link to neighboring directories, or at least close-by ones). >> >> > I think I need to understand it better. If I interpret it correctly then a > file set including a junction will cause the actual data to be backed-up. > Close, but not quite. The junction, and anything underneath, is simply disregarded. As John Drescher mentioned, you probably have to recreate it manually.
The data itself actually doesn't even sit under the junction in the first place. It's somewhere else in your file system. And it would get backed up *in that place*. > But what happens if the data has to be restored? Will the actual data be > restored together with the junction? > The actual data will be restored with the whatever directory it actually resides. For example, let's say that you have a junction point at C:\abc\def and it points to C:\abc\ghi (it could also point to D:\somethingcompletelydifferent but most junction points tend to point to close-by directories) When you back up C:\abc\def you will get the warning from bacula. When you restore, you will find all the data under C:\abc\ghi I would expect that either C:\abc\def does not exist at all, or that it is an empty directory. -- Kevin Keane Owner The NetTech Find the Uncommon: Expert Solutions for a Network You Never Have to Think About Office: 866-642-7116 http://www.4nettech.com This e-mail and attachments, if any, may contain confidential and/or proprietary information. Please be advised that the unauthorized use or disclosure of the information is strictly prohibited. The information herein is intended only for use by the intended recipient(s) named above. If you have received this transmission in error, please notify the sender immediately and permanently delete the e-mail and any copies, printouts or attachments thereof. ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
