Re: [bareos-users] Re: Delay job on incoming connect?
Of course, using external scripting I can do anything ;-)
I was wondering if there is anything built in. I don't think so.
MK
On 24.01.2024 14:03, Jörg Steffens wrote:
You could try to implement you own logic based on
https://github.com/bareos/bareos/tree/master/contrib/misc/triggerjob
So let a python script check for connected clients and start a job
when you criteria is matched. You would than disable "Run On Incoming
Connect Interval".
Regards,
Jörg
On 22.01.24 at 10:14 wrote spadaj...@gmail.com:
Hi.
Is there a possibiliry to delay a job from a passive client?
I have a job defined simply like this:
Job {
Name = "laptop"
JobDefs = "DefaultJob"
Schedule= "EarlyWeeklyCycle"
Fileset = "LinuxDocs"
Client = "laptop-fd"
Priority = 5
Run On Incoming Connect Interval = 12h
}
The client here has "connection from client to director=yes"
It's as simple as it gets.
And it works pretty good. The problem is that by default the laptop
connects to wifi on power on and while it's OK for most times,
sometimes (especially when I want to do the full backup) I want to
have it connected with cable ethernet. The problem is that right
after the power on the FD starts, connects to the director and the
backup job is spawned. And if I switch my connection from the default
wifi to cable, the job is left hanging on both sides (FD and dir) and
I have to restart both the FD and director. It's not pretty.
I'm wondering if I can do something to make it all more robust.
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/cb6b8767-f9bc-4802-b96a-7d6658140606n%40googlegroups.com
.
--
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/028922d9-ac19-4476-8da4-f458c8990b3e%40gmail.com.
Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process
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 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 14:16 dziura-fd JobId 17111:
> (S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ ->
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
> 22-Jan 14:16 dziura-fd JobId 17111:
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
> [...]
> Non-fatal FD errors:0
> SD Errors: 0
> FD termination status: OK
> SD termination status: OK
>
> *status client=dziura-fd
> [...]
> dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024) VSS Microsoft
> Windows 8 Professional (build 9200), 64-bit
>
>
> Thank you!
>
> MK
>
> On 22.01.2024 09:42, Sebastian Sura wrote:
>
> 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 tried that version and the issue
> still persists!
>
> Sincerly
>
> Sebastian Sura
> Am 18.01.24 um 19:53 schrieb Joshua Myles:
>
> 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 like
> maybe there's a different code path used when that's enabled, and it hits a
> bug. Unfortunately we can't switch away from client-initiated for these,
> we've just been living with the warnings.
>
> Josh
>
> On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj wrote:
>
> 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 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 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 installation just for testing the
> FD, this one is my production setup. Anyway, one thing that can be
> relatively uncommon (but I don't see why it should affect anything about
> the job itself) is that I use passive clients (Connection From Client to
> Director=yes, Heartbeat Interval=60).
>
> MK
>
> *list joblog jobid=17062
> Automatically selected Catalog: PgCatalog
> Using Catalog "PgCatalog"
> 2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup JobId 17062,
> Job=win10test-fd.2024-01-18_08.06.02_12
> 2024-01-18 08:06:04 backup1-dir JobId 17062: Connected Storage daemon at
> backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
> 2024-01-18 08:06:04 backup1-dir JobId 17062: Encryption:
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
> 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client Initiated
> Connection (dziura-fd).
> 2024-01-18 08:06:04 backup1-dir JobId 17062: Handshake: Immediate TLS
> 2024-01-18 08:06:04 backup1-dir JobId 17062: Encryption:
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
> 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device "vchanger-1-0"
> to write.
> 2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27 wildcard excludes
> from FilesNotToBackup Registry key
> 2024-01-18 08:06:03 dziura-fd JobId 17062: Connected Storage daemon at
> backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
> 2024-01-18 08:06:03 dziura-fd JobId 17062: Encryption:
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
> 2024-01-18 08:06:05 bareos-sd JobId 17062: Volume "vchanger-1_0002_0042"
> previously written, moving to end of data.
> 2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append to end of
> Volume "vchanger-1_0002_0042" size=26886488931
> 2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS snapshots.
> Driver="Win64 VSS"
> 2024-01-18 08:06:07 dziura-fd JobId 17062:
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
>
[bareos-users] Re: Delay job on incoming connect?
You could try to implement you own logic based on
https://github.com/bareos/bareos/tree/master/contrib/misc/triggerjob
So let a python script check for connected clients and start a job when
you criteria is matched. You would than disable "Run On Incoming Connect
Interval".
Regards,
Jörg
On 22.01.24 at 10:14 wrote spadaj...@gmail.com:
Hi.
Is there a possibiliry to delay a job from a passive client?
I have a job defined simply like this:
Job {
Name = "laptop"
JobDefs = "DefaultJob"
Schedule= "EarlyWeeklyCycle"
Fileset = "LinuxDocs"
Client = "laptop-fd"
Priority = 5
Run On Incoming Connect Interval = 12h
}
The client here has "connection from client to director=yes"
It's as simple as it gets.
And it works pretty good. The problem is that by default the laptop
connects to wifi on power on and while it's OK for most times, sometimes
(especially when I want to do the full backup) I want to have it
connected with cable ethernet. The problem is that right after the power
on the FD starts, connects to the director and the backup job is
spawned. And if I switch my connection from the default wifi to cable,
the job is left hanging on both sides (FD and dir) and I have to restart
both the FD and director. It's not pretty.
I'm wondering if I can do something to make it all more robust.
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/cb6b8767-f9bc-4802-b96a-7d6658140606n%40googlegroups.com .
--
Jörg Steffens joerg.steff...@bareos.com
Bareos GmbH & Co. KGPhone: +49 221 630693-91
https://www.bareos.com Fax: +49 221 630693-10
Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz
--
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/uor1q9%24cij%241%40ciao.gmane.io.
Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process
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 from there. An upgrade to the
upcoming version 22.1.4 will be seamless.
Best Regards,
Andreas
Am 24.01.24 um 12:33 schrieb Joshua Myles:
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 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 14:16 dziura-fd JobId 17111:
(S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ ->
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
22-Jan 14:16 dziura-fd JobId 17111:
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
[...]
Non-fatal FD errors:0
SD Errors: 0
FD termination status: OK
SD termination status: OK
*status client=dziura-fd
[...]
dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024) VSS Microsoft
Windows 8 Professional (build 9200), 64-bit
Thank you!
MK
On 22.01.2024 09:42, Sebastian Sura wrote:
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/
[bareos-users] IS IT RIGHT TO BUY DMT VAPES ONLINE USING GOOGLE GROUPS |BUY DMT ONLINE
IS IT RIGHT TO BUY DMT VAPES ONLINE USING GOOGLE GROUPS |BUY DMT ONLINE https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ https://southparkpsychedelics.com/product-category/dmt-vapes-and-cartriges/ -- 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/74a5089c-4c0d-4a87-8edb-80d5df857342n%40googlegroups.com.
Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process
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 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 from there. An upgrade to the
> upcoming version 22.1.4 will be seamless.
>
> Best Regards,
> Andreas
>
> Am 24.01.24 um 12:33 schrieb Joshua Myles:
> > 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 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 14:16 dziura-fd JobId 17111:
> (S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ ->
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
> > 22-Jan 14:16 dziura-fd JobId 17111:
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
> > [...]
> > Non-fatal FD errors: 0
> > SD Errors: 0
> > FD termination status: OK
> > SD termination status: OK
> >
> > *status client=dziura-fd
> > [...]
> > dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024) VSS
> Microsoft Windows 8 Professional (build 9200), 64-bit
> >
> > Thank you!
> >
> > MK
> >
> > On 22.01.2024 09:42, Sebastian Sura wrote:
> >>
> >> 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/
> >>
