Discussion:
[bareos-users] NetApp NDMP disk-to-disk-to-tape backup not working
Justin Vrooman
2015-12-11 15:34:54 UTC
Permalink
I am attempting to do a disk-to-disk-to-tape job from my NetApp to local storage on the backup server and then off to a tape drive attached to my backup server. I have the disk-to-disk portion working using NDMP but I am unable to get the disk-to-tape migration to work. Here is how I have everything setup:

+==================================================+
+ bareos-dir.conf +
+==================================================+

#
# A NDMP Client.
#
Client {
Name = filer
Address = filer.egr.msu.edu
Port = 10000
Protocol = NDMPv4 # Need to specify protocol before password as protocol determines password encoding used.
Auth Type = MD5 # Clear == Clear Text, MD5 == Challenge protocol
Username = "root" # username of the NDMP user on the DATA AGENT e.g. storage box being backuped.
Password = "password1" # password of the NDMP user on the DATA AGENT e.g. storage box being backuped.
}

Fileset {
Name = "NDMP Test Fileset"
Include {
Options {
meta = "USER=root"
}
File = /vol/test_vol
}
}

JobDefs {
Name = "NDMPTestJobDef"
Type = Backup
Protocol = NDMP
Level = Full
Client = filer
Backup Format = dump
FileSet = "NDMP Test Fileset"
Schedule = "WeeklyCycle"
Storage = NDMPFile
Messages = Standard
Pool = NDMPFile
Priority = 10
#Write Bootstrap = "/var/opt/bareos/run/bareos/%c.bsr"
}

#
# A NDMP Backup Job using the JobDef above.
#
Job {
Name = "NDMPTestJob"
JobDefs = "NDMPTestJobDef"
Level = Full
}

#
# Define the migration job
#
Job {
Name = "NDMPMigrateAll"
Type = Migrate
Level = Full
Messages = Standard
Selection Type = Volume
Selection Pattern = "."
Pool = NDMPFile
Maximum Concurrent Jobs = 4
}

# (why?)
# Seperate Pool for NDMP data so upgrading of Jobs works and selects the right storage.
#
Pool {
Name = NDMPFile
Pool Type = Backup
#Recycle = yes
#AutoPrune = yes
Next Pool = Tape
# This Storage line overrides any specified in the Job. Recommended here.
Storage = NDMPFile
#Volume Retention = 365 days # one year
#Maximum Volume Bytes = 50G # Limit Volume size to something reasonable
#Maximum Volumes = 100 # Limit number of Volumes in Pool
# The value defined by this directive in the bareos-dir.conf file is the default value used when a Volume is created. Once the volume is created, changing the value in the bareos-dir.conf file will not change what is stored for the Volume. To change the value for an existing Volume you must use the update command in the Console.
# This makes a new volume file per backup job, just to try it in testing
Maximum Volume Jobs = 1
Label Format = "NDMPFull-" # Volumes will be labeled "Full-<volume-id>"
}

#
# Tape pool definition
#
Pool {
Name = Tape
Pool Type = Backup
# AutoPrune = yes
# Recycle = yes
Storage = LTO5Drive
}

#
# "Same storage daemon (as File) but via NDMP protocol."
# We link via the PairedStorage config option the Bareos SD instance definition to a NDMP TAPE AGENT.
#
Storage {
Name = NDMPFile
Address = hostname.egr.msu.edu # N.B. Use a fully qualified name here
# DECS: because the netapp needs to connect to us!
Port = 10000
Protocol = NDMPv4 # Need to specify protocol before password as protocol determines password encoding used.
Auth Type = Clear # Clear == Clear Text, MD5 == Challenge protocol
Username = ndmp # username of the NDMP user on the TAPE AGENT e.g. the Bareos SD but accessed via the NDMP protocol.
Password = password2 # password of the NDMP user on the TAPE AGENT e.g. the Bareos SD but accessed via the NDMP protocol.
Device = FileStorage
Media Type = File
PairedStorage = File
}

#
# Definition of LTO-5 tape storage device
#
Storage {
Name = LTO5Drive
Address = hostname
Password = "password3"
Device = "Drive-1" # same as Device in Storage daemon
Media Type = LTO-5 # same as MediaType in Storage daemon
}



+==================================================+
+ bareos-sd.conf +
+==================================================+

Storage { # definition of myself
Name = hostname-sd
Maximum Concurrent Jobs = 20

# remove comment from "Plugin Directory" to load plugins from specified directory.
# if "Plugin Names" is defined, only the specified plugins will be loaded,
# otherwise all storage plugins (*-sd.so) from the "Plugin Directory".
#
# Plugin Directory = /usr/lib64/bareos/plugins
# Plugin Names = ""
NDMP Enable = yes
NDMP Log Level = 10
NDMP Snooping = yes
}

#
# List Directors who are permitted to contact Storage daemon
#
Director {
Name = hostname-dir
Password = "password3"
}

#
# Restricted Director, used by tray-monitor to get the
# status of the storage daemon
#
Director {
Name = hostname-mon
Password = "password4"
Monitor = yes
}

#
# Devices supported by this Storage daemon
# To connect, the Director's bareos-dir.conf must have the same Name and MediaType.
#
Device {
Name = FileStorage
Media Type = File
Archive Device = /VL
LabelMedia = yes; # lets Bareos label unlabeled media
Random Access = yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = no;
AlwaysOpen = no;
}

#
# include additional configuration files, if required
#

# eg.
#@/etc/bareos/bareos-sd.d/device-gluster.conf
# Tape Drives
#----------------------------------
Autochanger {
Name = Autochanger
Device = Drive-1, Drive-2, Drive-3, Drive-4
Changer Command = "/usr/lib/bareos/scripts/mtx-changer %c %o %S %a %d"
Changer Device = /dev/changer
}

Device {
Name = Drive-1
Drive Index = 0
Media Type = LTO-5
Archive Device = /dev/nst3 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

Device {
Name = Drive-2
Drive Index = 1
Media Type = LTO-5
Archive Device = /dev/nst2 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

Device {
Name = Drive-3
Drive Index = 2
Media Type = LTO-5
Archive Device = /dev/nst1 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

Device {
Name = Drive-4
Drive Index = 3
Media Type = LTO-5
Archive Device = /dev/nst0 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

#
# Send all messages to the Director,
# mount messages also are sent to the email address
#
Messages {
Name = Standard
director = hostname-dir = all
}

Ndmp {
Name = 10amd64-default-job-01-dir # Can be any name but normally you should use the name of the Director here.
Username = ndmp # Same username as you specified in the NDMPFile storage definition.
Password = password2 # Same password as you specified in the NDMPFile storage definition.
# MD5 failed, so....
AuthType = Clear # Clear == Clear Text, MD5 == Challenge protocol
Log Level = 5
}



With all of this. The NDMP backup to disk works. The disk to tape backup then fails as follows:

+==================================================+
+ Excerpt from Log +
+==================================================+

11-Dec 10:26 hostname-dir JobId 166: The following 1 JobId was chosen to be migrated: 124
11-Dec 10:26 hostname-dir JobId 166: Automatically selected Catalog: MyCatalog
11-Dec 10:26 hostname-dir JobId 166: Using Catalog "MyCatalog"
11-Dec 10:26 hostname-dir JobId 167: Migration using JobId=124 Job=NDMPTestJob.2015-12-10_14.19.35_04
11-Dec 10:26 hostname-dir JobId 167: Bootstrap records written to /var/lib/bareos/hostname-dir.restore.1.bsr
11-Dec 10:26 hostname-dir JobId 166: Job queued. JobId=167
11-Dec 10:26 hostname-dir JobId 166: Migration JobId 167 started.
11-Dec 10:26 hostname-dir JobId 166: Bareos hostname-dir 15.2.2 (16Nov15):
Build OS: x86_64-redhat-linux-gnu redhat Red Hat Enterprise Linux Server release 6.5 (Santiago)
Current JobId: 166
Current Job: NDMPMigrateAll.2015-12-11_10.26.43_04
Catalog: "MyCatalog" (From Default catalog)
Start time: 11-Dec-2015 10:26:45
End time: 11-Dec-2015 10:26:46
Elapsed time: 1 sec
Priority: 10
Termination: Migration -- OK

11-Dec 10:26 hostname-dir JobId 167: Start Migration JobId 167, Job=NDMPMigrateAll.2015-12-11_10.26.46_05
11-Dec 10:26 hostname-dir: ERROR in authenticate.c:232 Failed ASSERT: store->password.encoding == p_encoding_md5

Then the director crashes. Can anyone see any problems?



Also, As a test I have tried doing a local disk-to-disk-to tape backup and that sort of silently "fails" reporting "Migration -- OK" after 0 seconds and not copying anything to tape. The director does not crash in this instance. Can someone tell me where I am going wrong or offer suggestions of things to try?
--
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+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Justin Vrooman
2015-12-11 15:36:44 UTC
Permalink
I am attempting to do a disk-to-disk-to-tape job from my NetApp to local storage on the backup server and then off to a tape drive attached to my backup server. I have the disk-to-disk portion working using NDMP but I am unable to get the disk-to-tape migration to work. Here is how I have everything setup:

+==================================================+
+ bareos-dir.conf +
+==================================================+

#
# A NDMP Client.
#
Client {
Name = filer
Address = filer.domain.com
Port = 10000
Protocol = NDMPv4 # Need to specify protocol before password as protocol determines password encoding used.
Auth Type = MD5 # Clear == Clear Text, MD5 == Challenge protocol
Username = "root" # username of the NDMP user on the DATA AGENT e.g. storage box being backuped.
Password = "password1" # password of the NDMP user on the DATA AGENT e.g. storage box being backuped.
}

Fileset {
Name = "NDMP Test Fileset"
Include {
Options {
meta = "USER=root"
}
File = /vol/test_vol
}
}

JobDefs {
Name = "NDMPTestJobDef"
Type = Backup
Protocol = NDMP
Level = Full
Client = filer
Backup Format = dump
FileSet = "NDMP Test Fileset"
Schedule = "WeeklyCycle"
Storage = NDMPFile
Messages = Standard
Pool = NDMPFile
Priority = 10
#Write Bootstrap = "/var/opt/bareos/run/bareos/%c.bsr"
}

#
# A NDMP Backup Job using the JobDef above.
#
Job {
Name = "NDMPTestJob"
JobDefs = "NDMPTestJobDef"
Level = Full
}

#
# Define the migration job
#
Job {
Name = "NDMPMigrateAll"
Type = Migrate
Level = Full
Messages = Standard
Selection Type = Volume
Selection Pattern = "."
Pool = NDMPFile
Maximum Concurrent Jobs = 4
}

# (why?)
# Seperate Pool for NDMP data so upgrading of Jobs works and selects the right storage.
#
Pool {
Name = NDMPFile
Pool Type = Backup
#Recycle = yes
#AutoPrune = yes
Next Pool = Tape
# This Storage line overrides any specified in the Job. Recommended here.
Storage = NDMPFile
#Volume Retention = 365 days # one year
#Maximum Volume Bytes = 50G # Limit Volume size to something reasonable
#Maximum Volumes = 100 # Limit number of Volumes in Pool
# The value defined by this directive in the bareos-dir.conf file is the default value used when a Volume is created. Once the volume is created, changing the value in the bareos-dir.conf file will not change what is stored for the Volume. To change the value for an existing Volume you must use the update command in the Console.
# This makes a new volume file per backup job, just to try it in testing
Maximum Volume Jobs = 1
Label Format = "NDMPFull-" # Volumes will be labeled "Full-<volume-id>"
}

#
# Tape pool definition
#
Pool {
Name = Tape
Pool Type = Backup
# AutoPrune = yes
# Recycle = yes
Storage = LTO5Drive
}

#
# "Same storage daemon (as File) but via NDMP protocol."
# We link via the PairedStorage config option the Bareos SD instance definition to a NDMP TAPE AGENT.
#
Storage {
Name = NDMPFile
Address = hostname.domain.com # N.B. Use a fully qualified name here
# DECS: because the netapp needs to connect to us!
Port = 10000
Protocol = NDMPv4 # Need to specify protocol before password as protocol determines password encoding used.
Auth Type = Clear # Clear == Clear Text, MD5 == Challenge protocol
Username = ndmp # username of the NDMP user on the TAPE AGENT e.g. the Bareos SD but accessed via the NDMP protocol.
Password = password2 # password of the NDMP user on the TAPE AGENT e.g. the Bareos SD but accessed via the NDMP protocol.
Device = FileStorage
Media Type = File
PairedStorage = File
}

#
# Definition of LTO-5 tape storage device
#
Storage {
Name = LTO5Drive
Address = hostname
Password = "password3"
Device = "Drive-1" # same as Device in Storage daemon
Media Type = LTO-5 # same as MediaType in Storage daemon
}



+==================================================+
+ bareos-sd.conf +
+==================================================+

Storage { # definition of myself
Name = hostname-sd
Maximum Concurrent Jobs = 20

# remove comment from "Plugin Directory" to load plugins from specified directory.
# if "Plugin Names" is defined, only the specified plugins will be loaded,
# otherwise all storage plugins (*-sd.so) from the "Plugin Directory".
#
# Plugin Directory = /usr/lib64/bareos/plugins
# Plugin Names = ""
NDMP Enable = yes
NDMP Log Level = 10
NDMP Snooping = yes
}

#
# List Directors who are permitted to contact Storage daemon
#
Director {
Name = hostname-dir
Password = "password3"
}

#
# Restricted Director, used by tray-monitor to get the
# status of the storage daemon
#
Director {
Name = hostname-mon
Password = "password4"
Monitor = yes
}

#
# Devices supported by this Storage daemon
# To connect, the Director's bareos-dir.conf must have the same Name and MediaType.
#
Device {
Name = FileStorage
Media Type = File
Archive Device = /VL
LabelMedia = yes; # lets Bareos label unlabeled media
Random Access = yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = no;
AlwaysOpen = no;
}

#
# include additional configuration files, if required
#

# eg.
#@/etc/bareos/bareos-sd.d/device-gluster.conf
# Tape Drives
#----------------------------------
Autochanger {
Name = Autochanger
Device = Drive-1, Drive-2, Drive-3, Drive-4
Changer Command = "/usr/lib/bareos/scripts/mtx-changer %c %o %S %a %d"
Changer Device = /dev/changer
}

Device {
Name = Drive-1
Drive Index = 0
Media Type = LTO-5
Archive Device = /dev/nst3 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

Device {
Name = Drive-2
Drive Index = 1
Media Type = LTO-5
Archive Device = /dev/nst2 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

Device {
Name = Drive-3
Drive Index = 2
Media Type = LTO-5
Archive Device = /dev/nst1 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

Device {
Name = Drive-4
Drive Index = 3
Media Type = LTO-5
Archive Device = /dev/nst0 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Fast Forward Space File = no;
BSF at EOM = yes;
TWO EOF = yes;
}

#
# Send all messages to the Director,
# mount messages also are sent to the email address
#
Messages {
Name = Standard
director = hostname-dir = all
}

Ndmp {
Name = 10amd64-default-job-01-dir # Can be any name but normally you should use the name of the Director here.
Username = ndmp # Same username as you specified in the NDMPFile storage definition.
Password = password2 # Same password as you specified in the NDMPFile storage definition.
# MD5 failed, so....
AuthType = Clear # Clear == Clear Text, MD5 == Challenge protocol
Log Level = 5
}



With all of this. The NDMP backup to disk works. The disk to tape backup then fails as follows:

+==================================================+
+ Excerpt from Log +
+==================================================+

11-Dec 10:26 hostname-dir JobId 166: The following 1 JobId was chosen to be migrated: 124
11-Dec 10:26 hostname-dir JobId 166: Automatically selected Catalog: MyCatalog
11-Dec 10:26 hostname-dir JobId 166: Using Catalog "MyCatalog"
11-Dec 10:26 hostname-dir JobId 167: Migration using JobId=124 Job=NDMPTestJob.2015-12-10_14.19.35_04
11-Dec 10:26 hostname-dir JobId 167: Bootstrap records written to /var/lib/bareos/hostname-dir.restore.1.bsr
11-Dec 10:26 hostname-dir JobId 166: Job queued. JobId=167
11-Dec 10:26 hostname-dir JobId 166: Migration JobId 167 started.
11-Dec 10:26 hostname-dir JobId 166: Bareos hostname-dir 15.2.2 (16Nov15):
Build OS: x86_64-redhat-linux-gnu redhat Red Hat Enterprise Linux Server release 6.5 (Santiago)
Current JobId: 166
Current Job: NDMPMigrateAll.2015-12-11_10.26.43_04
Catalog: "MyCatalog" (From Default catalog)
Start time: 11-Dec-2015 10:26:45
End time: 11-Dec-2015 10:26:46
Elapsed time: 1 sec
Priority: 10
Termination: Migration -- OK

11-Dec 10:26 hostname-dir JobId 167: Start Migration JobId 167, Job=NDMPMigrateAll.2015-12-11_10.26.46_05
11-Dec 10:26 hostname-dir: ERROR in authenticate.c:232 Failed ASSERT: store->password.encoding == p_encoding_md5

Then the director crashes. Can anyone see any problems?



Also, As a test I have tried doing a local disk-to-disk-to tape backup and that sort of silently "fails" reporting "Migration -- OK" after 0 seconds and not copying anything to tape. The director does not crash in this instance. Can someone tell me where I am going wrong or offer suggestions of things to try?
--
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+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marco van Wieringen
2015-12-12 15:42:11 UTC
Permalink
...
Post by Justin Vrooman
+==================================================+
+ Excerpt from Log +
+==================================================+
11-Dec 10:26 hostname-dir JobId 166: The following 1 JobId was chosen to be migrated: 124
11-Dec 10:26 hostname-dir JobId 166: Automatically selected Catalog: MyCatalog
11-Dec 10:26 hostname-dir JobId 166: Using Catalog "MyCatalog"
11-Dec 10:26 hostname-dir JobId 167: Migration using JobId=124 Job=NDMPTestJob.2015-12-10_14.19.35_04
11-Dec 10:26 hostname-dir JobId 167: Bootstrap records written to /var/lib/bareos/hostname-dir.restore.1.bsr
11-Dec 10:26 hostname-dir JobId 166: Job queued. JobId=167
11-Dec 10:26 hostname-dir JobId 166: Migration JobId 167 started.
Build OS: x86_64-redhat-linux-gnu redhat Red Hat Enterprise Linux Server release 6.5 (Santiago)
Current JobId: 166
Current Job: NDMPMigrateAll.2015-12-11_10.26.43_04
Catalog: "MyCatalog" (From Default catalog)
Start time: 11-Dec-2015 10:26:45
End time: 11-Dec-2015 10:26:46
Elapsed time: 1 sec
Priority: 10
Termination: Migration -- OK
11-Dec 10:26 hostname-dir JobId 167: Start Migration JobId 167, Job=NDMPMigrateAll.2015-12-11_10.26.46_05
11-Dec 10:26 hostname-dir: ERROR in authenticate.c:232 Failed ASSERT: store->password.encoding == p_encoding_md5
Then the director crashes. Can anyone see any problems?
The problem is that the so called read storage of the migration or copy
Job is a NDMP storage definition and that is why the ASSERT is
triggered. The director not really crashes but an assert is implemented
as a fatal error dumping the core of the process. For Backup and Restore
we map the NDMP storage definition to the paired storage definition and
as such we can address the Bareos SD via its native protocol. For
migration and copy Jobs that mapping is missing. I had a quick look at
it last night while traveling back from Cologne and think I know what to
do but as I am having vacation not much will happen this year.

For now its an unsupported feature as we don't have any paying customers
doing DTDTT with NDMP. Given your install you could think about a payed
subscription for Bareos and the NDMP plugin and it that way make this a
bit more prioritized. We are currently doing some more NDMP enhancements
but those are all based on external funded development or for bug of
actual customers. As the fix for the above problem will go into 15.2.3
at best it does mean either running the experimental packages or compile
it yourself if you don't want to pay for a subscription.

B.T.W. the above shows the new behavior as of Bareos 15.2 where the
selection job for migration and copy runs and spawns the actual work
to be done. The scheduled work Job then fails because of the problem
described above.
Post by Justin Vrooman
Also, As a test I have tried doing a local disk-to-disk-to tape backup and that sort of silently "fails" reporting "Migration -- OK" after 0 seconds and not copying anything to tape. The director does not crash in this instance. Can someone tell me where I am going wrong or offer suggestions of things to try?
I guess it didn't find anything to migrate then. Which can happen
depending on your settings.
--
Marco van Wieringen ***@bareos.com
Bareos GmbH & Co. KG Phone: +49-221-63069389
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
P. Storz, M. v. Wieringen
--
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+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Justin Vrooman
2015-12-13 00:00:26 UTC
Permalink
Post by Marco van Wieringen
The problem is that the so called read storage of the migration or copy
Job is a NDMP storage definition and that is why the ASSERT is
triggered. The director not really crashes but an assert is implemented
as a fatal error dumping the core of the process. For Backup and Restore
we map the NDMP storage definition to the paired storage definition and
as such we can address the Bareos SD via its native protocol. For
migration and copy Jobs that mapping is missing. I had a quick look at
it last night while traveling back from Cologne and think I know what to
do but as I am having vacation not much will happen this year.
For now its an unsupported feature as we don't have any paying customers
doing DTDTT with NDMP. Given your install you could think about a payed
subscription for Bareos and the NDMP plugin and it that way make this a
bit more prioritized. We are currently doing some more NDMP enhancements
but those are all based on external funded development or for bug of
actual customers. As the fix for the above problem will go into 15.2.3
at best it does mean either running the experimental packages or compile
it yourself if you don't want to pay for a subscription.
B.T.W. the above shows the new behavior as of Bareos 15.2 where the
selection job for migration and copy runs and spawns the actual work
to be done. The scheduled work Job then fails because of the problem
described above.
Thank you for saving me some time. I had been trying and trying to get this working. What level of support would need to be purchased to make this a relatively high priority? My department would really like to use Bareos but DTDTT with NDMP is a must. If we can purchase a Subscription + Support and get it into the code base early next year then Bareos could still be a viable option for us.

Can you explain what you think needs to be done? I'm a programmer (although not familiar with the Bareos code base) but I would be interested in looking at the issue. I doubt I would be able to successfully implement it but it would still be interesting to take a look at.

Thanks,
- Justin
--
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+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marco van Wieringen
2015-12-13 08:38:02 UTC
Permalink
Post by Justin Vrooman
Thank you for saving me some time. I had been trying and trying to get this working. What level of support would need to be purchased to make this a relatively high priority? My department would really like to use Bareos but DTDTT with NDMP is a must. If we can purchase a Subscription + Support and get it into the code base early next year then Bareos could still be a viable option for us.
Someone will contact you early next week as I saw you also send
a request to bareos.com. Don't think it makes sense to do this
negotiations via a public mailinglist.
Post by Justin Vrooman
Can you explain what you think needs to be done? I'm a programmer (although not familiar with the Bareos code base) but I would be interested in looking at the issue. I doubt I would be able to successfully implement it but it would still be interesting to take a look at.
Essentially you need to call the set_paired_storage() and on when done
free_paired_storage() but then only for the read storage. Currently the
code assumes when you have write storage in your Job it needs to apply
it to that (e.g. being a backup Job) and only adjusts the read storage
when there is NO write storage. That needs to change for copy/migrate
Jobs so we need something a little more clever. And we need to change
has_paired_storage() so that we only do this when a Copy/Migrate Job
needs this as now we only call the set_paired_storage() from the
specific NDMP backup or restore code so then we are pretty sure we
need to do so. As we plan on eventually supporting native NDMP storage
this needs to change anyway.

I did a small prototype which contains what I think needs to change
but the work is more in things like verifying no other side effects
happen and that this addresses the problems etc. It was more that
my train trip last Friday took a bit longer due to some delays along
the way that I had some time to work on some problems. But I'm now
already answering while I have planned a vacation so from me not a lot
will happen the next weeks. Given that the company (and most companies
do) will be somewhat silent the last 2 weeks of the year we probably
will continue either early next year but there are some other things
we have for funded development that need my attention. But if you are
a paying customer we could see if we can have someone do some
preliminary testing of my current prototype and provide you with some
custom build packages build out of that code. When we internally publish
code it gets build by our build system for testing etc. so
if you work with our sales guys think we can work out some kind of
arrangement. I guess the technical stuff is the easiest the contracting
stuff tends to be always taking the most of the time.
--
Marco van Wieringen ***@bareos.com
Bareos GmbH & Co. KG Phone: +49-221-63069389
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
P. Storz, M. v. Wieringen
--
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+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...