Hi Spadapjspadaj, When we examine what happen on test machine here we see it working correctly. Especially that the VSS is present.
you may think we don't backup the snapshot due to the presence of *C:/Users/user/NTUSER.dat* in the log, but you need to understand that is the resulting file name after its conversion in compact.cccompat/compat.cc: 555-307 Leave make_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\user\NTUSER.dat compat/compat.cc:1609-307 sizino=8 ino=0 filename=C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (300): findlib/find_one.cc:911-307 File ----: C:/Users /user/NTUSER.dat desktop-vcf7e32-fd (130): filed/backup.cc:535-307 FT_REG saving: C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (130): filed/backup.cc:646-307 filed: sending C:/Users/user/NTUSER.dat to stored So to be sure we use the same code, could you please install and run the following bareos-fd https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe In your director you set the debug level to 500 for that client (changing the client name in the following example) setdebug level=500 trace=1 timestamp=1 client=windows-fd this will indicate where the tracelog will be written (often directly on C:\) run one backup job then disable the debugging, To extract in text mode the joblog in bconsole @out /tmp/backup-win-fd.joblog list joblog jobid=XXXXX q Then you can zip and attach both trace and joblog here. Add the fileset used too. BTW please ensure your fileset contain Enable VSS = yes as stated in documentation and Windows fileset example. Le mardi 16 janvier 2024 à 15:38:37 UTC+1, Spadajspadaj a écrit : I used the relatively new available client. (23-pre-something, downloaded around 2 weeks ago). Yes, I should have written that explicitly. On 16.01.2024 15:23, Bruno Friedmann (bruno-at-bareos) wrote: Hello, all normally the issues that are described here, should have been already fixed, and should work without any trouble with bareos >= 23 The code fixing the problem has been submitted and merge a certain time ago with PR1452 https://github.com/bareos/bareos/pull/1452 Please refresh your installation, and of course report success and failures. Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit : As I understand, this is the interesting excerpt from the debug trace. win10test-fd (50): findlib/find.cc:169-0 Verify=<V> Accurate=<Cmcs> BaseJob=<Jspug5> flags=<724185736> win10test-fd (50): findlib/find.cc:169-0 Verify=<V> Accurate=<Cmcs> BaseJob=<Jspug5> flags=<724185736> win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path win10test-fd (500): compat/compat.cc:322-0 path = \\?\C:\Users\test\NTUSER.DAT win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path path=\\?\C:\Users\test\NTUSER.DAT win10test-fd (500): compat/compat.cc:234-0 Win32ConvInitCache: Setup of thread specific cache at address 1532b2b76d0 win10test-fd (500): compat/compat.cc:531-0 Enter make_wchar_win32_path win10test-fd (500): compat/compat.cc:555-0 Leave make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT win10test-fd (500): compat/compat.cc:1609-0 sizino=8 ino=0 filename=C:/Users/test/NTUSER.DAT win10test-fd (300): findlib/find_one.cc:911-0 File ----: C:/Users/test/NTUSER.DAT win10test-fd (130): filed/backup.cc:535-0 FT_REG saving: C:/Users/test/NTUSER.DAT win10test-fd (130): filed/backup.cc:646-0 filed: sending C:/Users/test/NTUSER.DAT to stored win10test-fd (150): lib/crypto_openssl.cc:641-0 crypto_digest_new jcr=1532b228410 win10test-fd (300): filed/backup.cc:1575-0 encode_and_send_attrs fname=C:/Users/test/NTUSER.DAT win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path win10test-fd (500): compat/compat.cc:322-0 path = \\?\C:\Users\test\NTUSER.DAT win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path path=\\?\C:\Users\test\NTUSER.DAT win10test-fd (300): filed/backup.cc:1594-0 File C:/Users/test/NTUSER.DAT attribs=A A IH/ B A A CAi FAAA A A BlnTaz BlnTaz BlnTaz A A L attribsEx=CAi HaQkZzohoU HaQvQ8Q7yY HaQvQ8Q7yY A FAAA win10test-fd (300): filed/backup.cc:1620-0 >stored: attrhdr 1 5 0win10test-fd (200): filed/backup.cc:1772-0 No strip for C:/Users/test/NTUSER.DAT win10test-fd (300): filed/backup.cc:1715-0 >stored: attr len=130: 1 3 C:/Users/test/NTUSER.DAT win10test-fd (150): filed/backup.cc:737-0 type=3 do_read=1 win10test-fd (100): findlib/bfile.cc:710-0 bopen: fname C:/Users/test/NTUSER.DAT, flags 00100000, mode 0000, rdev 8226 win10test-fd (50): findlib/bfile.cc:565-0 === NO plugin win10test-fd (100): findlib/bfile.cc:664-0 Read CreateFileW=\\?\C:\Users\test\NTUSER.DAT win10test-fd (850): lib/message.cc:1216-0 Enter Jmsg type=8 win10test-fd (850): lib/message.cc:613-0 Enter DispatchMessage type=8 msg=win10test-fd JobId 16959: Cannot open "C:/Users/test/NTUSER.DAT": ERR=The process cannot access the file because it is being used by another process. . win10test-fd (850): lib/message.cc:820-0 DIRECTOR for following msg: win10test-fd JobId 16959: Cannot open "C:/Users/test/NTUSER.DAT": ERR=The process cannot access the file because it is being used by another process. . win10test-fd (400): findlib/find_one.cc:493-0 FT_REG FI=1 linked=0 file=C:/Users/test/NTUSER.DAT >From what I understand from the description of the make_wchar_win32_path() method in win32/compat/compat.cc - we should leave the function with the filename properly converted to VSS-based one. But apparently we're stuck with local name. MK On 11.01.2024 22:03, Spadajspadaj wrote: The more I dig into it, the more it seems it is bareos after all. Unfortunately, building Windows bareos-fd is no small feat so I cannot directly debug it but. I ran a procmon against bareos-fd.exe and it seems that while the FD process does create a VSS snapshot... it doesn't read from it. It reads the files straight from the main device. I did a small test fileset consisting of just my user's registry file. And both procmon's dump as well as bareos-fd own debug trace shows that it's trying to read simply a c:\users\test\ntuser.dat instead of properly going for \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopyXX\Users\test\ntuser.dat. That would explain why the job even though it's supposed to use VSS, fails on copying open files. When I created a very small example VS project just creating a VSS snapshot and copying said file out of the VSS snapshot (using the proper shadow copy volume path), it works OK. MK -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/d7a59124-2d32-4f0e-8e5b-f2fb6264a34dn%40googlegroups.com.
