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 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367
|
Embedding full NDMP support in BAREOS.
No filed plugin but a proper implementation with support in
the director to act as a NDMP DMA (Data Management Application)
and for NDMP tape agent support in the storage daemon for saving
data using the NDMP protocol.
This code is based on the NDMJOB NDMP reference implementation
of Traakan, Inc., Los Altos, CA which has a BSD style license
(2 clause one).
http://www.traakan.com/ndmjob/index.html
We imported the latest actively supported version of this
reference NDMP code from the Amanda project. Instead of
basing it on glib what Amanda has done we reverted some changes
back to the way the latest spinnaker sources of the NDMJOB code
deliver things with per OS specific code.
The robot and tape simulator are rewritten versions from NDMJOB
with support for registering callbacks in the calling code. This
way we can implement virtual tape and robot functionality in the
storage daemon for handling NDMP backups.
There is also some code added for registering authentication
callbacks in the calling code. This way we can perform clear
text and md5 based authentication against the internal config
data we keep in BAREOS native resources.
The core fileindex handling code is rewritten to use callback
functions for doing the real work. This way we can hook in
internal functions into the core file indexing process which
happens after a backup and before a restore to fill the
files which have been backuped or restored.
Some missing initialization, commission and decommission is
added although it is empty it is better to have a consistent
coding path/style for everything. Added extra destroy method
as for some agents a decommission means make it ready for a next
run and we want something that does a tear down and cleanup
of anything dynamically allocated during a NDMP run.
We also added support for telling the initialization upfront
what NDMP services it should support. (e.g. DATA MANAGEMENT
APPLICATION (DMA), DATA AGENT, TAPE AGENT or ROBOT AGENT)
so when we accept a connection in the storage daemon via
ndmp_tape we only allow the client to use our NDMP TAPE AGENT
and not the ROBOT, DMA and DATA AGENT. See ndm_session structure
members ..._agent_enabled.
We also rewrote some of the internal structures. Normally
a NDMP session is described by a so called ndm_session struct
which is a whopping 1442392 bytes (almost 1.4 Mb) in size.
The coders decided they would allocate each array up front
and as such the total structure is huge. This is not very
handy when using it as a base for a shared library as we want
to support all agents but possibly not at the same time
(even most likely not at the same time.)
So the new ndm_session struct has pointers to the individual
members and storage is only allocated when things are needed
we also only allocate buffers at the time we need them not
upfront. For things like directory names or other pathnames
we just strdup the actual string and free it on decommission
of the data, this saves a lot when PATH_MAX = 1024 bytes and
you stuff a directory path of lets say 30 bytes.
The DMA and DATA AGENT also keep track of an list of environment
variables and a name list structure. In the original code the
environment variable list can have a maximum of 1024 entries
and 10240 entries for the name list and that is allocated as
one big array of either 1024 or 10240 entries. This is
madness we rewrote the list code to use a normal linked
list so we only need the space to store the actual number
of nodes of each list. There is a enumerate function which
returns a memory chunk with all entries concatenated which
is used for the rpc calls. We keep track of this enumerate
buffer in the list descriptor and when the list is torn down
it is freed. (We cannot free it earlier as it is needed
as buffer for the returning rpc call.) This lingering of
a buffer should be no problem as it should be moderate in
size now and not the whopping 1024 or 10240 entries anymore.
The media table is also rewritten to a linked list and not
a fixed list of 40 entries as it was in the old code.
This has significant size advantages to give an idea:
ndm_control_agent, original size 523000 bytes, new size 928 bytes
ndm_data_agent, original size 553232 bytes, new size 304 bytes
ndm_tape_agent, original size 263388 bytes, new size 228 bytes
ndm_plumbing, original size 102592 bytes, new size 20 bytes
As we initialize some things now later we needed to add some
extra checks and things may core dump due to dereferencing
a null pointer. We decided to take that as a risk and fix
those problems which we encounter them. Adding extra checks
all over the place checking if things are not initialized is
also gross overkill and as NDMP is a nice state machine we
probably can get away by putting checks in strategic places.
The test routines are put into an extra define named
NDMOS_OPTION_NO_TEST_AGENTS so one can disable them for a
production shared library.
Extra support for getaddrinfo() is added to the library
which supercedes the old and by POSIX deprecated gethostbyname()
interface. Also the implementation of poll() is completed and
we now also check the return info from poll() and set the
channel ready flag if we detect something on a channel. This
way the poll() handler should be on par with the select()
based poller.
The ndmjob program code is also included and you can build
the ndmjob binary using the new shared library. Currently
it is mostly for testing the new code in the shared library.
The ndmjob program code is rewritten to also use linked list
whereever possible without the need to completely rewrite the
code.
The NDMJOB header files are made C++ aware so we can compile
the shared lib a pure C-code (which it essentially also is)
and use it from BAREOS.
The config engine of the director and storage daemon have been
made aware of the NDMP protocol. Currently there is support for
creating NDMP protocol based Backup and Restore Jobs. The storage
resource is extended with a protocol and authentication type field
which can be used by the NDMP DMA coded in ndmp_dma.c. A Client
also has those two fields. When a storage daemon used in the NDMP
backup/restore is in real life an BAREOS storage daemon an extra
field named paired storage is part of the storage resource and is
used by the DMA to contact the storage daemon via the native protocol
to be able to simulate a NDMP save or restore via the normal
BAREOS infrastructure. Via the native protocol we reserve
things like drives etc so the virtual NDMP tape client can
save its data, the native link is also used for things like
getting the next volume to load etc.
The job start code for backup and restore is modified to check
for the job protocol and dispatch to the native routines when
it is a native backup or to the NDMP routines when it is any NDMP job.
The NDMP tape agent lives in ndmp_tape.c in the storage
daemon it creates an extra listening thread which handles NDMP
connections. Its based on the BAREOS bnet_server_thread code but
put somewhat on a diet as for NDMP we don't need all the bells
and whistles from the bsock class so we implemented a light weight
ndmp connection structure. This structure is passed as handle to
the connection handler and could be seen as local hook data and
can be extended along the way to keep some state information on
the NDMP session related to internal BAREOS resources.
A ndmp backup configuration looks somethings like this:
Configuration in bareos-dir.conf:
Replace <ndmp_data_server> with the hostname of the storage device
you are backing up e.g. the DATA AGENT in NDMP terms.
#
# Use the DUMP protocol (e.g. UNIX DUMP comparable to tar/cpio)
# Generates FileHandle Information which can be used for single file
# restore.
#
JobDefs {
Name = "DefaultNDMPJob"
Type = Backup
Protocol = NDMP
Level = Incremental
Client = <ndmp_data_server>-ndmp
Backup Format = dump
FileSet = "NDMP Fileset"
Schedule = "WeeklyCycle"
Storage = NDMPFile
Messages = Standard
Pool = NDMPFile
Priority = 10
Write Bootstrap = "/var/opt/bareos/run/bareos/%c.bsr"
}
#
# A special restore Job which has the protocol set right etc.
#
JobDefs {
Name = "DefaultNDMPRestoreJob"
Client = <ndmp_data_server>-ndmp
Type = Restore
Protocol = NDMP
Backup Format = dump
FileSet = "NDMP Fileset"
Storage = NDMPFile
Pool = Default
Messages = Standard
Where = /
}
#
# A NDMP Backup Job using the JobDef above.
#
Job {
Name = "BackupNDMPDump"
JobDefs = "DefaultNDMPJob"
}
#
# Use the NETAPP SMTAPE protocol e.g. same protocol is used as replication protocol
# between two NETAPP storage boxes. Doesn't allow single file restore all or nothing
# restore of whole NETAPP volume.
#
Job {
Name = "BackupNDMPSMTape"
JobDefs = "DefaultNDMPJob"
Backup Format = smtape
Client = <ndmp_data_server>-ndmp
FileSet = "NDMP SMtape Fileset"
}
#
# A NDMP restore Job using the JobDef above.
#
Job {
Name = "NDMPRestoreDump"
JobDefs = "DefaultNDMPRestoreJob"
}
#
# A NDMP restore Job using the JobDef above but for restoring a SMTAPE type of NDMP backup.
#
Job {
Name = "NDMPRestoreSMTape"
JobDefs = "DefaultNDMPRestoreJob"
Backup Format = smtape
FileSet = "NDMP SMtape Restore Fileset"
}
Fileset {
Name = "NDMP Fileset"
Include {
Options {
meta = "USER=root"
}
File = /export/home/...
}
}
#
# A NDMP Backup using SMPTAPE of a NetAPP storage box.
#
Fileset {
Name = "NDMP SMtape Fileset"
Include {
Options {
meta = "SMTAPE_DELETE_SNAPSHOT=Y"
}
File = /vol/vol1
}
}
#
# A NDMP Restore using SMPTAPE of a NetAPP storage box.
#
Fileset {
Name = "NDMP SMtape Restore Fileset"
Include {
Options {
meta = "SMTAPE_BREAK_MIRROR=Y"
}
File = /vol/vol1
}
}
#
# A NDMP Client.
#
Client {
Name = <ndmp_data_server>-ndmp
Address = ...
Port = 10000
Protocol = NDMPv4
Auth Type = Clear # Clear == Clear Text, MD5 == Challenge protocol
Username = "ndmp" # username of the NDMP user on the DATA AGENT e.g. storage box being backuped.
Password = "test" # password of the NDMP user on the DATA AGENT e.g. storage box being backuped.
}
#
# Your normal Bareos SD definition should be already in your config.
#
Storage {
Name = File
Address = ... # N.B. Use a fully qualified name here
SDPort = 9103
Password = ...
Device = FileStorage
Media Type = File
}
#
# Same storage daemon 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 = ... # N.B. Use a fully qualified name here
Port = 10000
Protocol = NDMPv4
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 = test # 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
}
#
# Your normal File based backup pool normally already defined.
#
Pool {
Name = File
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Storage = File
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
}
#
# 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
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
}
Configuration in bareos-sd.conf:
#
# Normal SD config block, should enable the NDMP protocol here otherwise it won't listen
# on port 10000.
#
Storage {
Name = ....
...
NDMP Enable = yes
}
#
# This entry gives the DMA in the Director access to the bareos SD via the NDMP protocol.
# This option is used via the NDMP protocol to open the right TAPE AGENT connection to your
# Bareos SD via the NDMP protocol. The initialization of the SD is done via the native protocol
# and is handled via the PairedStorage keyword.
#
Ndmp {
Name = ...-ndmp-dma # 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 = test # Same password as you specified in the NDMPFile storage definition.
AuthType = Clear # Clear == Clear Text, MD5 == Challenge protocol
}
|