Checking in to provide a report on 22.1.4 and the VSS issue for
client-initiated connections. We have 11 Windows FDs using client-initiated
connections, and nearly all of them would previously give VSS warnings
(ERR=The process cannot access the file because it is being used by another
They can be found here: https://download.bareos.org/current/
Sincerly
Sebastian Sura
Am 25.01.24 um 21:20 schrieb 'jo.go...@hosted-power.com' via bareos-users:
Where do I find the 23 pre release? I only see version 22 on the link
shared earlier? :)
On Thursday 25 January 2024 at 09:30:56
Where do I find the 23 pre release? I only see version 22 on the link
shared earlier? :)
On Thursday 25 January 2024 at 09:30:56 UTC+1 Andreas Rogge wrote:
> Yes, it is in the pre-release for 23 and also for 21.
>
> Am 24.01.24 um 20:59 schrieb 'jo.go...@hosted-power.com' via bareos-users:
> >
Yes, it is in the pre-release for 23 and also for 21.
Am 24.01.24 um 20:59 schrieb 'jo.go...@hosted-power.com' via bareos-users:
Ok that is cool, this similar exists for Bareos 23? Since we're already
on 23.0.1, the 22.x would be also a lower version :)
On Wednesday 24 January 2024 at
Ok that is cool, this similar exists for Bareos 23? Since we're already on
23.0.1, the 22.x would be also a lower version :)
On Wednesday 24 January 2024 at 16:49:31 UTC+1 Andreas Rogge wrote:
> Hi Josh,
>
> the backport has already happened in PR 1667. You can try the
> pre-release packages
Hi Josh,
the backport has already happened in PR 1667. You can try the
pre-release packages from these subscription repositories:
https://download.bareos.com/bareos/testing/CD/bareos-22
Version 22.1.4~pre39 (and every newer version) should contain the fix.
You can safely install the packages
I've only tested with one client, but 24.0.0~pre187.8e12c147a did work with
no VSS errors. I'll be watching for this to be backported to 22
(subscription).
Josh
On Monday, January 22, 2024 at 11:37:51 AM UTC-5 Spadajspadaj wrote:
> Yes, it does seem to be working!
>
> 22-Jan 14:16 dziura-fd
Yes, it does seem to be working!
22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots. Driver="Win64 VSS"
22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as
onefs = yes.
22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as
onefs = yes.
22-Jan
We managed to reproduce the issue. As you already noted, the cause was
the "connection from client to director" option.
This was fixed by https://github.com/bareos/bareos/pull/1665
The current next release ( https://download.bareos.org/next/ ) already
contains the fix. Let me know if you
Interesting. We have a mix of client-initiated and not, and at a glance it
looks like the only jobs that ever have warnings ("ERR=The process cannot
access the file because it is being used by another process.") are the ones
from clients with "Connection From Client To Director = yes". Seems
Yes. It does seem to be the cause.
I switched the client connectivity to the "normal" mode (director to
client) and the job completed OK and I had no problems accessing the
registry file.
MK
On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via bareos-users wrote:
Coindidence or not, we
Coindidence or not, we also use Connection From Client to Director=yes
Coindidence or not, Another host which does not have this setting, has 0
errors!
On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj wrote:
> Hi Sebastian.
>
> Thx for looking into it. This is the job log. Not much
Hi Sebastian.
Thx for looking into it. This is the job log. Not much interesting stuff
in there.
The same thing (the jobid being zero in the trace log) was in the
previous trace I attached excerpt from few days ago. But that one was
from a different machine. That was a clean win10
Hi Spadajspadaj,
something is wrong with your debug output but im not sure why. Debug
messages are normally formatted as
daemon-name (level):file:line-jobid
For some reason your jobid is 0 (which often means it could not be
determined) here.
This should normally not happen and might be why
OK. I had a few spare minutes. I did upgrade to the pre57 release I
downloaded today from https://download.bareos.org/current/windows/
The fileset is very simple so that the job is quick and short. It
consists of just one file from the windows registry (so that it will be
open for sure).
Please, may I ask you to either provided the trace and job log as requested.
As I can argue that we are using 2019 to 2022 with 0% of your troubles
That kind of guerilla can be endless.
If we have traces, joblog fileset etc we may have a chance to reproduce.
If it is reproducible, then there's
I just
tried
https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe
on Windows 2022. But I still have 100's of failed in use files :/
On Wednesday 17 January 2024 at 09:49:10 UTC+1 Spadajspadaj wrote:
> Hi Bruno.
>
> Yes, I understand how it's
Hi Bruno.
Yes, I understand how it's supposed to work. :-)
OK, I will re-run the tests when I have a spare minute and dump the
trace somewhere (the excerpt I posted earlier was with debug level 999
so all messages should have been captured).
And it's not that I _thought_ it wasn't backed
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
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
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
As I understand, this is the interesting excerpt from the debug trace.
win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate=
BaseJob= flags=<724185736>
win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate=
BaseJob= flags=<724185736>
win10test-fd (450): findlib/find.cc:175-0 F
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.
OK. There is more to this than just bareos.
1. I used the script from this thread and it seems to be working relatively
well for backing up (I'm yet to test the restore part ;-)) the disk. I
don't know, however how to backup whole mountpoint. If I put the location
of my
We have simuilar issues, it seems for some servers a lot is skipped. We
would really like to get to the root cause
On Wednesday, 21 December 2022 at 04:19:35 UTC+1 Matt Bader wrote:
> Hi Timo and Andreas,
>
> I'd be interested to know how to handle this issue as well - it's
> happening to a
Hi Timo and Andreas,
I'd be interested to know how to handle this issue as well - it's happening
to a number of my FDs too. Did you figure out how to get VSS to work on all
files?
Thanks and regards,
Matt
On Friday, February 11, 2022 at 6:21:59 PM UTC+1 zehnb...@gmail.com wrote:
> Hey
Hey Andreas,
Windows Server Backup is working.
Those 3 files are just files to demonstrate that somehow the bareos-vss is
not working. Like i already mentioned, as a workaround i can create a vss
with a powershell-script and ClientRunBeforeJob, then backup and remove the
vss with
Am 07.02.22 um 08:20 schrieb Vorname Nachname:
Any suggestions?
Check if the integrated Windows Server Backup works or not.
Are you backing up only these three files, or are the other files where
the backup works?
Best Regards,
Andreas
--
Andreas Rogge
28 matches
Mail list logo
