Re: [Bacula-users] bacula-fd appearing to use wrong storage server

2024-04-25 Thread Bill Arlofski via Bacula-users

On 4/25/24 3:55 PM, gaston.gloesener--- via Bacula-users wrote:

Thanks for the rplies,

I include here some of the requested informations.

First abouth the "bconsole reload", yes I did not do, but I did restart the 
director, the storage and file deamons several times after the config change. Also 
because I did run them in forground with debug.


Hello Gaston,


I am re-sending this since the last one I sent I had included a screenshot which will not translate well for search engines, 
etc...


The problem had pointed out in the screenshot was that it looks like you are using the `FDStorageAddress` setting in this 
client. I believe this is causing your issue.:

8<> *show job=Backup-james1

Job: name=Backup-james1 JobType=66 level=Incremental Priority=10 Enabled=1
  MaxJobs=1 NumJobs=0 Resched=0 Times=0 Interval=1,800 Spool=0 
WritePartAfterJob=1
  Accurate=1
   --> Client: Name=james1-fd Enabled=1 Address=james1.home FDport=9102 MaxJobs=

1 NumJobs=0

JobRetention=6 months  FileRetention=2 months  AutoPrune=1



  FDStorageAddress=bacula.home   
<--- HERE



   --> Catalog: name=MyCatalog address=*None* DBport=0 db_name=bacula
   db_driver=PostgreSQL db_user=bacula MutliDBConn=0
   --> FileSet: name=Full Set IgnoreFileSetChanges=0

8<

If this is not it, we will look a little deeper. :)


Hope this helps,
Bill

--
Bill Arlofski
w...@protonmail.com



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] bacula-fd appearing to use wrong storage server

2024-04-25 Thread gaston.gloesener--- via Bacula-users
Thanks for the rplies,

I include here some of the requested informations.

First abouth the "bconsole reload", yes I did not do, but I did restart the 
director, the storage and file deamons several times after the config change. 
Also because I did run them in forground with debug.

*show job=Backup-james1
Job: name=Backup-james1 JobType=66 level=Incremental Priority=10 Enabled=1
 MaxJobs=1 NumJobs=0 Resched=0 Times=0 Interval=1,800 Spool=0 
WritePartAfterJob=1
 Accurate=1
  --> Client: Name=james1-fd Enabled=1 Address=james1.home FDport=9102 
MaxJobs=1 NumJobs=0
   JobRetention=6 months  FileRetention=2 months  AutoPrune=1
 FDStorageAddress=bacula.home
  --> Catalog: name=MyCatalog address=*None* DBport=0 db_name=bacula
  db_driver=PostgreSQL db_user=bacula MutliDBConn=0
  --> FileSet: name=Full Set IgnoreFileSetChanges=0
  O Z6MAKcXf
  X ext2
  X ext4
  X xfs
  X zfs
  X brtfs
  N
  I /
  N
  E /opt/bacula/working
  E /tmp
  E /proc
  E /tmp
  E /sys
  E /.journal
  E /.fsck
  E /dev
  E /media
  E /mnt
  N
  --> Schedule: Name=WeeklyCycle Enabled=1
  --> Run Level=Full
  hour=1
  mday=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 
26 27 28 29 30
  month=0 1 2 3 4 5 6 7 8 9 10 11
  wday=1
  wom=0
  woy=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 
52 53
  mins=0
  --> Run Level=Differential
  hour=1
  mday=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 
26 27 28 29 30
  month=0 1 2 3 4 5 6 7 8 9 10 11
  wday=1
  wom=1 2 3 4
  woy=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 
52 53
  mins=0
  --> Run Level=Incremental
  hour=1
  mday=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 
26 27 28 29 30
  month=0 1 2 3 4 5 6 7 8 9 10 11
  wday=0 2 3 4 5 6
  wom=0 1 2 3 4 5
  woy=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 
52 53
  mins=0
  --> WriteBootstrap=/opt/bacula/working/%c.bsr
  --> Autochanger: name=vTape1 address=bacula.home SDport=9103 MaxJobs=2 
NumJobs=0
  DeviceName=vChanger1 MediaType=vtape1 StorageId=3 Autochanger=1
  AC group=3 ShareStore=*none*
  --> Pool: name=Full-Backup-Pool PoolType=Backup
  use_cat=1 use_once=0 cat_files=1
  max_vols=0 auto_prune=1 VolRetention=3 months 11 days
  VolUse=0 secs recycle=1 LabelFormat=Full-
  CleaningPrefix=*None* LabelType=0
  RecyleOldest=0 PurgeOldest=0 ActionOnPurge=0
  MaxVolJobs=1 MaxVolFiles=0 MaxVolBytes=200
  MaxPoolBytes=0
  MigTime=0 secs MigHiBytes=0 MigLoBytes=0
  CacheRetention=0 secs
  JobRetention=0 secs FileRetention=0 secs
  Catalog=MyCatalog
  --> Autochanger: name=vTape1 address=bacula.home SDport=9103 MaxJobs=2 
NumJobs=0
  DeviceName=vChanger1 MediaType=vtape1 StorageId=3 Autochanger=1
  AC group=3 ShareStore=*none*
  --> FullBackupPool: name=james1-Full-Pool PoolType=Backup
  use_cat=1 use_once=0 cat_files=1
  max_vols=0 auto_prune=1 VolRetention=3 months 11 days
  VolUse=0 secs recycle=1 LabelFormat=james1-full-
  CleaningPrefix=*None* LabelType=0
  RecyleOldest=0 PurgeOldest=0 ActionOnPurge=0
  MaxVolJobs=1 MaxVolFiles=0 MaxVolBytes=200
  MaxPoolBytes=0
  MigTime=0 secs MigHiBytes=0 MigLoBytes=0
  CacheRetention=0 secs
  JobRetention=0 secs FileRetention=0 secs
  Catalog=MyCatalog
  --> Autochanger: name=vTape2 address=nas1.home SDport=9103 MaxJobs=2 NumJobs=0
  DeviceName=vChanger2 MediaType=vtape2 StorageId=5 Autochanger=1
  AC group=5 ShareStore=*none*
  --> IncrementalBackupPool: name=james1-Incr-Pool PoolType=Backup
  use_cat=1 use_once=0 cat_files=1
  max_vols=0 auto_prune=1 VolRetention=1 month 9 days
  VolUse=0 secs recycle=1 LabelFormat=james1-incr-
  CleaningPrefix=*None* LabelType=0
  RecyleOldest=0 PurgeOldest=0 ActionOnPurge=0
  MaxVolJobs=5 MaxVolFiles=0 MaxVolBytes=200
  MaxPoolBytes=0
  MigTime=0 secs MigHiBytes=0 MigLoBytes=0
  CacheRetention=0 secs
  JobRetention=0 secs FileRetention=0 secs
  Catalog=MyCatalog
  --> Autochanger: name=vTape2 address=nas1.home SDport=9103 MaxJobs=2 NumJobs=0
  DeviceName=vChanger2 MediaType=vtape2 StorageId=5 Autochanger=1
  AC group=5 ShareStore=*none*
  --> DifferentialBackupPool: name=james1-Diff-Pool PoolType=Backup
  use_cat=1 use_once=0 cat_files=1
  max_vols=0 auto_prune=1 VolRetention=3 months 11 days
  VolUse=0 secs recycle=1 LabelFormat=james1-diff-
  CleaningPrefix=*None* LabelType=0
  RecyleOldest=0 PurgeOldest=0 

Re: [Bacula-users] bacula-fd appearing to use wrong storage server

2024-04-25 Thread Bill Arlofski via Bacula-users

On 4/25/24 3:17 AM, gaston.gloesener--- via Bacula-users wrote:
>
Until now I did run bacula in a virtual machine running the director and storage deamon. The storage daemon was stroing data 
to files on a shared directory as the storage is on a NAS.


Now I have build bacula-sd for the NAS to avoid this duplicate transfer. I have configured one client to use the new storage 
but while it uses it, it claims to still contact the “old” storage daemon on the bacula node.


Hello Gaston,

A bconsole `show job=` will show what the Director knows about this job.

It is quite possible, and my guess that one of two possible things has happened:

#1: You forgot to issue the bconsole reload command
#2: The Director has reached its default configuration reload limit of 32 and 
is no longer reloading


You can check with:

* status director

...and look at the header line:

`Daemon started 24-Apr-24 18:55, conf reloaded 24-Apr-2024 18:55:27`

If the `conf reloaded` time is not recent, then you have hit #2 above and 
simply need to restart the Director.


Hope this helps,
Bill

--
Bill Arlofski
w...@protonmail.com



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] bacula-fd appearing to use wrong storage server

2024-04-25 Thread Martin Simmons
It would be useful to see the bacula-dir.conf Job and Client resources for
this job and also the full job log.

__Martin


> On Thu, 25 Apr 2024 11:17:18 +0200, gaston gloesener--- via Bacula-users 
> said:
> 
> Until now I did run bacula in a virtual machine running the director and 
> storage deamon. The storage daemon was stroing data to files on a shared 
> directory as the storage is on a NAS.
>  
> Now I have build bacula-sd for the NAS to avoid this duplicate transfer. I 
> have configured one client to use the new storage but while it uses it, it 
> claims to still contact the “old” storage daemon on the bacula node.
>  
> Using bacula 13.0.4
>  
> Here is the storage definition in bacula-dir.conf (vTape1 is the original 1, 
> vTape2 the new one): 
> Storage {
>   Name = "vTape1"
>   SdPort = 9103
>   Address = "bacula.home "
>   Password = "…deleted…"
>   Device = "vChanger1"
>   MediaType = "vtape1"
>   Autochanger = "vTape1"
>   MaximumConcurrentJobs = 2
> }
> Storage {
>   Name = "vTape2"
>   SdPort = 9103
>   Address = "nas1.home "
>   Password = "…deleted…"
>   Device = "vChanger2"
>   MediaType = "vtape2"
>   Autochanger = "vTape2"
>   MaximumConcurrentJobs = 2
> }
>  
> The client pool definition looks now like:
>  
> Pool {
>   Name = "james1-Full-Pool"
>   Description = "Pool for client james1 full backups"
>   PoolType = "Backup"
>   LabelFormat = "james1-full-"
>   MaximumVolumeJobs = 1
>   MaximumVolumeBytes = 200
>   VolumeRetention = 8726400
>   Storage = "vTape2"
>   Catalog = "MyCatalog"
> }
>  
> I have tried a manual and the scheduled job with same result:
>  
> *(James1-fd says:
>  
> 25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server  
> Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103 
> s=0x7fa01c01ac88
> 2
>  
> The full log:
>  
> 25-Apr-2024 01:00:00 james1-fd: bnet_server.c:235-0 Accept 
> socket=10.1.10.111.9102:10.1.200.12.45200 s=0x563bfba72728
> 25-Apr-2024 01:00:00 james1-fd: authenticate.c:67-0 authenticate dir: Hello 
> Director bacula-dir calling 10002 tlspsk=100
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:365-0 TLSPSK Remote need 
> 100
> 25-Apr-2024 01:00:00 james1-fd: authenticate.c:90-0 *** No FD compression to 
> DIR
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-0 TLSPSK Local need 
> 100
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:563-0 TLSPSK Start PSK
> 25-Apr-2024 01:00:00 james1-fd: bnet.c:96-0 TLS server negotiation 
> established.
> 25-Apr-2024 01:00:00 james1-fd: cram-md5.c:68-0 send: auth cram-md5 challenge 
> <2032624038.1713999600@james1-fd> ssl=0
> 25-Apr-2024 01:00:00 james1-fd: cram-md5.c:156-0 sending resp to challenge: 
> L6/ZMB/xti+re9kmB4sR+D
> 25-Apr-2024 01:00:00 james1-fd: events.c:48-0 Events: code=FC0002 
> daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir 
> text=Director connection
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:1714-7062 Instantiate 
> plugin_ctx=563bfbb34378 JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378 
> JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0 
> plugin=bpipe-fd.so plen=5
> 25-Apr-2024 01:00:00 james1-fd: job.c:2499-7062 level_cmd: level = full  
> mtime_only=0
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378 
> JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0 
> plugin=bpipe-fd.so plen=5
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378 
> JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0 
> plugin=bpipe-fd.so plen=5
> 25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server  
> Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103 
> s=0x7fa01c01ac88
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-7062 TLSPSK Local 
> need 100
> 25-Apr-2024 01:00:05 james1-fd: hello.c:183-7062 Recv caps from SD failed. 
> ERR=Success
> 25-Apr-2024 01:00:05 james1-fd: hello.c:185-7062 Recv caps from SD failed. 
> ERR=Success
> 25-Apr-2024 01:00:05 james1-fd: events.c:48-7062 Events: code=FC0001 
> daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir 
> text=Director disconnection
> 25-Apr-2024 01:00:05 james1-fd: fd_plugins.c:1749-7062 Free instance 
> plugin_ctx=563bfbb34378 JobId=7062
>  
> The job log on the director confirms:
>  
> 2024-04-25 01:00:00 bacula-dir JobId 7062: Connected to Storage "vTape2" at 
> bacula.home:9103 with TLS
>  
> So correct storage but bad server. Note that vTape 2 has always been pointing 
> to nas1 (not bacula) and the director (as well as james1-fd and both storage 
> deamons) was restarted several times
>  
> The storage daemon on nas1 reports only a connection from the director, the 
> ip address of the client (10.1.10.111) is never seen:
>  
> 25-Apr-2024 01:00:00 nas1-sd: bnet_server.c:235-0 Accept 
> 

Re: [Bacula-users] VSS

2024-04-25 Thread Radosław Korzeniewski
Hello,

śr., 24 kwi 2024 o 10:21 Mehrdad Ravanbod 
napisał(a):

> Hi
>
> You right in saying that bacula can use VSS to do backups in Windows
> systems, however It is my understanding that the VSS backup file is put
> into a "volume" file which makes it not accesible to VSS tools. In a
> windows system u can do straight VSS backup which can then be read by VSS
> tools and chcked/restored, however this not practical when there are many
> clients even with automation via powershell or other form of scripting.
> having a backup system to easily check the state of backups and keeping
> track of them is abetter solution, which is why i am considering bacula
>
> As I said i am new to bacula, so it maybe that it is possible to do
> backups(VSS or otherwise) with bacula that does not use "Volume" files(I am
> backing up to disk, not a a tape drive)
>
So you are not referring to VSS, but any backup created by Bacula, right?
You are concerned that Bacula creates a Bacula Volume or Volumes, where all
backups are stored. Is this what you want to avoid?
It is not about VSS, but how Bacula stores its backups?

> So I guess this is what my questions is, is it possible to get Bacula to
> do backups with VSS(or even otherwise, simple file copying with or without
> compression/encryption) without using "Volume" files, i.e the backup files
> are saved as indiviual files and not all put together in a "volume" file.
>
A simple question is no. You can't create a fully working, platform
independent backup without using Volume files (which are basically archive
files like zip, tar, etc.). A single file backup includes multiple data
streams for this file: metadata, data, acl data, xattr data, resource
forks, encryption data, deduplication references, etc. Bacula Volume can
store all different backup streams in a single file you can copy elsewhere
having all data you require for full recovery. Even a billion files can be
saved in the single volume in the space efficient, optimal way.
OTOH, why do you need to avoid Bacula Volume? This volume is like tar or
zip, and people do your backups with it without complaints.

> The volume files seem to be there more for a tape based system, the
> concept is not really neded if you are backing up to disk
>
Not true. A single file (volume) has advantages on disks too: it is a
single directory entry, faster throughput on both write and read, space
efficient especially for small files, platform independent, support
multiple streams and distinct attributes for single file, easy and fast
copy to different location or machine, etc.
An advantage one could think of is that a restore from directory tree
archive could be faster for a multi-terabyte backup when you need to
restore a single small file. But Bacula keeps track of every file archived
in volume (some kind of indexing) and such restore takes almost no time as
Bacula can seek to the required location and read from there - for every
distinct file. So, no advantage at all.

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


[Bacula-users] bacula-fd appearing to use wrong storage server

2024-04-25 Thread gaston.gloesener--- via Bacula-users
Until now I did run bacula in a virtual machine running the director and 
storage deamon. The storage daemon was stroing data to files on a shared 
directory as the storage is on a NAS.

 

Now I have build bacula-sd for the NAS to avoid this duplicate transfer. I have 
configured one client to use the new storage but while it uses it, it claims to 
still contact the “old” storage daemon on the bacula node.

 

Using bacula 13.0.4

 

Here is the storage definition in bacula-dir.conf (vTape1 is the original 1, 
vTape2 the new one): 

Storage {

  Name = "vTape1"

  SdPort = 9103

  Address = "bacula.home "

  Password = "…deleted…"

  Device = "vChanger1"

  MediaType = "vtape1"

  Autochanger = "vTape1"

  MaximumConcurrentJobs = 2

}

Storage {

  Name = "vTape2"

  SdPort = 9103

  Address = "nas1.home "

  Password = "…deleted…"

  Device = "vChanger2"

  MediaType = "vtape2"

  Autochanger = "vTape2"

  MaximumConcurrentJobs = 2

}

 

The client pool definition looks now like:

 

Pool {

  Name = "james1-Full-Pool"

  Description = "Pool for client james1 full backups"

  PoolType = "Backup"

  LabelFormat = "james1-full-"

  MaximumVolumeJobs = 1

  MaximumVolumeBytes = 200

  VolumeRetention = 8726400

  Storage = "vTape2"

  Catalog = "MyCatalog"

}

 

I have tried a manual and the scheduled job with same result:

 

James1-fd says:

 

25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server  
Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103 
s=0x7fa01c01ac88

2

 

The full log:

 

25-Apr-2024 01:00:00 james1-fd: bnet_server.c:235-0 Accept 
socket=10.1.10.111.9102:10.1.200.12.45200 s=0x563bfba72728

25-Apr-2024 01:00:00 james1-fd: authenticate.c:67-0 authenticate dir: Hello 
Director bacula-dir calling 10002 tlspsk=100

25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:365-0 TLSPSK Remote need 100

25-Apr-2024 01:00:00 james1-fd: authenticate.c:90-0 *** No FD compression to DIR

25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-0 TLSPSK Local need 100

25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:563-0 TLSPSK Start PSK

25-Apr-2024 01:00:00 james1-fd: bnet.c:96-0 TLS server negotiation established.

25-Apr-2024 01:00:00 james1-fd: cram-md5.c:68-0 send: auth cram-md5 challenge 
<2032624038.1713999600@james1-fd> ssl=0

25-Apr-2024 01:00:00 james1-fd: cram-md5.c:156-0 sending resp to challenge: 
L6/ZMB/xti+re9kmB4sR+D

25-Apr-2024 01:00:00 james1-fd: events.c:48-0 Events: code=FC0002 
daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir 
text=Director connection

25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:1714-7062 Instantiate 
plugin_ctx=563bfbb34378 JobId=7062

25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378 
JobId=7062

25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0 
plugin=bpipe-fd.so plen=5

25-Apr-2024 01:00:00 james1-fd: job.c:2499-7062 level_cmd: level = full  
mtime_only=0

25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378 
JobId=7062

25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0 
plugin=bpipe-fd.so plen=5

25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378 
JobId=7062

25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0 
plugin=bpipe-fd.so plen=5

25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server  
Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103 
s=0x7fa01c01ac88

25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-7062 TLSPSK Local need 
100

25-Apr-2024 01:00:05 james1-fd: hello.c:183-7062 Recv caps from SD failed. 
ERR=Success

25-Apr-2024 01:00:05 james1-fd: hello.c:185-7062 Recv caps from SD failed. 
ERR=Success

25-Apr-2024 01:00:05 james1-fd: events.c:48-7062 Events: code=FC0001 
daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir 
text=Director disconnection

25-Apr-2024 01:00:05 james1-fd: fd_plugins.c:1749-7062 Free instance 
plugin_ctx=563bfbb34378 JobId=7062

 

The job log on the director confirms:

 

2024-04-25 01:00:00 bacula-dir JobId 7062: Connected to Storage "vTape2" at 
bacula.home:9103 with TLS

 

So correct storage but bad server. Note that vTape 2 has always been pointing 
to nas1 (not bacula) and the director (as well as james1-fd and both storage 
deamons) was restarted several times

 

The storage daemon on nas1 reports only a connection from the director, the ip 
address of the client (10.1.10.111) is never seen:

 

25-Apr-2024 01:00:00 nas1-sd: bnet_server.c:235-0 Accept 
socket=10.1.11.1.9103:10.1.200.12.40796 s=0x555d9b1de468

25-Apr-2024 01:00:00 nas1-sd: dircmd.c:195-0 Got a DIR connection at 
25-Apr-2024 01:00:00

25-Apr-2024 01:00:00 nas1-sd: authenticatebase.cc:365-0 TLSPSK Remote need 100

25-Apr-2024 01:00:00 nas1-sd: authenticatebase.cc:335-0 TLSPSK Local need 100

25-Apr-2024 01:00:00 nas1-sd: authenticatebase.cc:563-0 TLSPSK Start PSK


Re: [Bacula-users] VSS

2024-04-25 Thread Andrea Venturoli

On 4/24/24 10:21, Mehrdad Ravanbod wrote:

is it possible to get Bacula to 
do backups with VSS(or even otherwise, simple file copying with or 
without compression/encryption) without using "Volume" files, i.e the 
backup files are saved as indiviual files and not all put together in a 
"volume" file.


No.

 bye
av.


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users