1Troubleshooting 2=============== 3 4.. _section-debug-messages: 5 6Debug Messages 7-------------- 8 9The Bareos programs contain a lot of debug messages. Normally, these are not printed. See the :ref:`setdebug <bcommandSetdebug>` chapter about how to enable them. 10 11.. _AccessProblems: 12 13Client Access Problems 14---------------------- 15 16:index:`\ <single: Problem; Cannot Access a Client>`\ There are several reasons why a |dir| could not contact a client on a different machine. They are: 17 18- Check if the client file daemon is really running. 19 20- The Client address or port is incorrect or not resolved by DNS. See if you can ping the client machine using the same address as in the Client record. 21 22- You have a firewall, and it is blocking traffic on port 9102 between the Director’s machine and the Client’s machine (or on port 9103 between the Client and the Storage daemon machines). 23 24- If your system is using Tcpwrapper (:file:`hosts.allow` or :file:`hosts.deny` file), verify that is permitting access. 25 26- Your password or names are not correct in both the Director and the Client machine. Try configuring everything identical to how you run the client on the same machine as the Director, but just change the address. If that works, make the other changes one step at a time until it works. 27 28Some of the DNS and Firewall problems can be circumvented by configuring clients using :ref:`section-ClientInitiatedConnection` or as :ref:`PassiveClient`. 29 30Difficulties Connecting from the FD to the SD 31~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 32 33:index:`\ <single: Problem; Connecting from the FD to the SD>`\ 34 35If you are having difficulties getting one or more of your File daemons to connect to the Storage daemon, it is most likely because you have not used a fully qualified domain name on the :config:option:`dir/storage/Address`\ directive. That is the resolver on the File daemon’s machine (not on the Director’s) must be able to resolve the name you supply into an IP address. An example of an address that is guaranteed not to work: :strong:`localhost`. An example that 36may work: :strong:`bareos-sd1`. An example that is more likely to work: :strong:`bareos-sd1.example.com`. 37 38You can verify how a |fd| resolves a DNS name by the following command: 39 40:: 41 42 \begin{bconsole}{Test DNS resolution of the \bareosFd \name{bareos-fd}} 43 *<input>resolve client=bareos-fd NONEXISTINGHOSTNAME</input> 44 Connecting to Client bareos-fd at bareos:9102 45 bareos-fd: Failed to resolve NONEXISTINGHOSTNAME 46 *<input>resolve client=bareos-fd bareos-sd1.example.com</input> 47 Connecting to Client bareos-fd at bareos:9102 48 bareos-fd resolves bareos-sd1.example.com to host[ipv4;192.168.0.1] 49 \end{bconsole} 50 51If your address is correct, then make sure that no other program is using the port 9103 on the Storage daemon’s machine. The Bacula project has reserved these port numbers by IANA, therefore they should only be used by Bacula and its replacements like Bareos. However, apparently some HP printers do use these port numbers. A :command:`netstat -lntp` on the |sd|’s machine can determine who is listening on the 9103 port (used for FD to SD communications in Bareos). 52 53Authorization Errors 54~~~~~~~~~~~~~~~~~~~~ 55 56:index:`\ <single: Problem; Authorization Errors>`\ :index:`\ <single: Concurrent Jobs>`\ 57 58.. _AuthorizationErrors: 59 60 61 62For security reasons, Bareos requires that both the File daemon and the Storage daemon know the name of the Director as well as its password. As a consequence, if you change the Director’s name or password, you must make the corresponding change in the Storage daemon’s and in the File daemon’s configuration files. 63 64During the authorization process, the Storage daemon and File daemon also require that the Director authenticates itself, so both ends require the other to have the correct name and password. 65 66If you have edited the configuration files and modified any name or any password, and you are getting authentication errors, then your best bet is to go back to the original configuration files generated by the Bareos installation process. Make only the absolutely necessary modifications to these files – e.g. add the correct email address. Then follow the instructions in the :ref:`Running Bareos <TutorialChapter>` chapter of this manual. You will run a backup to disk and a restore. 67Only when that works, should you begin customization of the configuration files. 68 69Some users report that authentication fails if there is not a proper reverse DNS lookup entry for the machine. This seems to be a requirement of gethostbyname(), which is what Bareos uses to translate names into IP addresses. If you cannot add a reverse DNS entry, or you don’t know how to do so, you can avoid the problem by specifying an IP address rather than a machine name in the appropriate Bareos configuration file. 70 71Here is a picture that indicates what names/passwords in which files/Resources must match up: 72 73.. image:: /include/images/Conf-Diagram.* 74 :width: 80.0% 75 76 77 78 79In the left column, you will find the Director, Storage, and Client resources, with their names and passwords – these are all in the |dir| configuration. The right column is where the corresponding values should be found in the Console, Storage daemon (SD), and File daemon (FD) configuration files. 80 81Another thing to check is to ensure that the Bareos component you are trying to access has :strong:`Maximum Concurrent Jobs`\ set large enough to handle each of the Jobs and the Console that want to connect simultaneously. Once the maximum connections has been reached, each Bareos component will reject all new connections. 82 83.. _ConcurrentJobs: 84 85.. _section-Interleaving: 86 87Concurrent Jobs 88--------------- 89 90:index:`\ <single: Job; Concurrent Jobs>`\ :index:`\ <single: Running Concurrent Jobs>`\ :index:`\ <single: Concurrent Jobs>`\ 91 92Bareos can run multiple concurrent jobs. Using the :strong:`Maximum Concurrent Jobs`\ directives, you can configure how many and which jobs can be run simultaneously: 93 94|dir| 95 96 - :config:option:`dir/director/MaximumConcurrentJobs`\ 97 98 - :config:option:`dir/client/MaximumConcurrentJobs`\ 99 100 - :config:option:`dir/job/MaximumConcurrentJobs`\ 101 102 - :config:option:`dir/storage/MaximumConcurrentJobs`\ 103 104|sd| 105 106 - :config:option:`sd/storage/MaximumConcurrentJobs`\ 107 108 - :config:option:`sd/device/MaximumConcurrentJobs`\ 109 110|fd| 111 112 - :config:option:`fd/client/MaximumConcurrentJobs`\ 113 114For example, if you want two different jobs to run simultaneously backing up the same Client to the same Storage device, they will run concurrently only if you have set :strong:`Maximum Concurrent Jobs`\ greater than one in the :config:option:`Dir/Director`\ resource, the :config:option:`Dir/Client`\ resource, and the :config:option:`Dir/Storage`\ resource in |dir| configuration. 115 116When running concurrent jobs without :ref:`section-DataSpooling`, the volume format becomes more complicated, consequently, restores may take longer if Bareos must sort through interleaved volume blocks from multiple simultaneous jobs. This can be avoided by having each simultaneous job write to a different volume or by using data spooling We recommend that you read the :ref:`section-DataSpooling` of this manual first, 117then test your multiple concurrent backup including restore testing before you put it into production. 118 119When using random access media as backup space (e.g. disk), you should also read the chapter about :ref:`ConcurrentDiskJobs`. 120 121Below is a super stripped down :file:`bareos-dir.conf` file showing you the four places where the the file must be modified to allow the same job :config:option:`Dir/Job = NightlySave`\ to run up to four times concurrently. The change to the Job resource is not necessary if you want different Jobs to run at the same time, which is the normal case. 122 123.. code-block:: bareosconfig 124 :caption: Concurrent Jobs Example 125 126 # 127 # Bareos Director Configuration file -- bareos-dir.conf 128 # 129 Director { 130 Name = rufus-dir 131 Maximum Concurrent Jobs = 4 132 ... 133 } 134 Job { 135 Name = "NightlySave" 136 Maximum Concurrent Jobs = 4 137 Client = rufus-fd 138 Storage = File 139 ... 140 } 141 Client { 142 Name = rufus-fd 143 Maximum Concurrent Jobs = 4 144 ... 145 } 146 Storage { 147 Name = File 148 Maximum Concurrent Jobs = 4 149 ... 150 } 151 152Media VolWrites: integer out of range 153------------------------------------- 154 155:index:`\ <single: Errors; integer out of range>`\ :index:`\ <single: Catalog; Media; VolWrites>`\ 156 157In some situation, you receive an error message similar to this: 158 159.. code-block:: bconsole 160 161 12-Apr 15:10 bareos-dir JobId 15860: Fatal error: Catalog error updating Media record. sql_update.c:385 update UPDATE Media SET VolJobs=12,VolFiles=10,VolBlocks=155013,VolBytes=10000263168,VolMounts=233,VolErrors=0,VolWrites=2147626019,MaxVolBytes=0,VolStatus='Append',Slot=1,InChanger=1,VolReadTime=0,VolWriteTime=842658562655,LabelType=0,StorageId=3,PoolId=2,VolRetention=144000,VolUseDuration=82800,MaxVolJobs=0,MaxVolFiles=0,Enabled=1,LocationId=0,ScratchPoolId=0,RecyclePoolId=0,RecycleCount=201,Recycle=1,ActionOnPurge=0,MinBlocksize=0,MaxBlocksize=0 WHERE VolumeName='000194L5' failed: 162 ERROR: integer out of range 163 164The database column **VolWrites** in the **Media** table stores the number of write accesses to a volume. It is only used for statistics. 165 166However, it has happened that the number of write accesses exceeds the maximum value supported by the database column (on |postgresql| it is currently 2147483647, 32 bit, signed integer). The result is a database error, similar to the one mentioned above. 167 168As a temporary fix, just reset this counter: 169 170.. code-block:: bconsole 171 :caption: Reset the VolWrites counter 172 173 1000 OK: bareos-dir Version: 17.2.5 (14 Feb 2018) 174 Enter a period to cancel a command. 175 *<input>sqlquery</input> 176 Automatically selected Catalog: MyCatalog 177 Using Catalog "MyCatalog" 178 Entering SQL query mode. 179 Terminate each query with a semicolon. 180 Terminate query mode with a blank line. 181 Enter SQL query: <input>UPDATE Media SET VolWrites = 0 WHERE VolWrites > '2000000000';</input> 182 No results to list. 183 SELECT volwrites FROM media; volwrites > '0'; 184 +-----------+ 185 | volwrites | 186 +-----------+ 187 | 0 | 188 | 0 | 189 | 0 | 190 | 0 | 191 +-----------+ 192 Enter SQL query: 193 194In the long run, it is planed to modify the database schema to enable storing much larger numbers. 195 196.. _AnsiLabelsChapter: 197 198Tape Labels: ANSI or IBM 199------------------------ 200 201:index:`\ <single: Label; Tape Labels>`\ :index:`\ <single: Tape; Label; ANSI>`\ :index:`\ <single: Tape; Label; IBM>`\ 202 203By default, Bareos uses its own tape label (see :ref:`backward-compatibility-tape-format` and :config:option:`dir/pool/LabelType`\ ). However, Bareos also supports reading and write ANSI and IBM tape labels. 204 205Reading 206~~~~~~~ 207 208Reading ANSI/IBM labels is important, if some of your tapes are used by other programs that also support ANSI/IBM labels. For example, LTFS tapes :index:`\ <single: Tape; LTFS>`\ are indicated by an ANSI label. 209 210If your are running Bareos in such an environment, you must set :config:option:`sd/device/CheckLabels`\ to yes, otherwise Bareos will not recognize that these tapes are already in use. 211 212Writing 213~~~~~~~ 214 215To configure Bareos to also write ANSI/IBM tape labels, use :config:option:`dir/pool/LabelType`\ or :config:option:`sd/device/LabelType`\ . With the proper configuration, you can force Bareos to require ANSI or IBM labels. 216 217Even though Bareos will recognize and write ANSI and IBM labels, it always writes its own tape labels as well. 218 219If you have labeled your volumes outside of Bareos, then the ANSI/IBM label will be recognized by Bareos only if you have created the HDR1 label with BAREOS.DATA in the filename field (starting with character 5). If Bareos writes the labels, it will use this information to recognize the tape as a Bareos tape. This allows ANSI/IBM labeled tapes to be used at sites with multiple machines and multiple backup programs. 220 221.. _TapeTestingChapter: 222 223Tape Drive 224---------- 225 226:index:`\ <single: Problem; Tape>`\ 227 228This chapter is concerned with testing and configuring your tape drive to make sure that it will work properly with Bareos using the btape program. 229 230Get Your Tape Drive Working 231~~~~~~~~~~~~~~~~~~~~~~~~~~~ 232 233In general, you should follow the following steps to get your tape drive to work with Bareos. Start with a tape mounted in your drive. If you have an autochanger, load a tape into the drive. We use /dev/nst0 as the tape drive name, you will need to adapt it according to your system. 234 235Do not proceed to the next item until you have succeeded with the previous one. 236 237#. Make sure that Bareos (the Storage daemon) is not running or that you have unmounted the drive you will use for testing. 238 239#. Use tar to write to, then read from your drive: 240 241 242 243 :: 244 245 mt -f /dev/nst0 rewind 246 tar cvf /dev/nst0 . 247 mt -f /dev/nst0 rewind 248 tar tvf /dev/nst0 249 250 251 252#. Make sure you have a valid and correct Device resource corresponding to your drive. For Linux users, generally, the default one works. For FreeBSD users, there are two possible Device configurations (see below). For other drives and/or OSes, you will need to first ensure that your system tape modes are properly setup (see below), then possibly modify you Device resource depending on the output from the btape program (next item). When doing this, you should consult the 253 :ref:`Storage Daemon Configuration <StoredConfChapter>` of this manual. 254 255#. If you are using a Fibre Channel to connect your tape drive to Bareos, please be sure to disable any caching in the NSR (network storage router, which is a Fibre Channel to SCSI converter). 256 257#. Run the btape test command: 258 259 260 261 :: 262 263 btape /dev/nst0 264 test 265 266 267 268 It isn’t necessary to run the autochanger part of the test at this time, but do not go past this point until the basic test succeeds. If you do have an autochanger, please be sure to read the :ref:`Autochanger chapter <AutochangersChapter>` of this manual. 269 270#. Run the btape fill command, preferably with two volumes. This can take a long time. If you have an autochanger and it is configured, Bareos will automatically use it. If you do not have it configured, you can manually issue the appropriate mtx command, or press the autochanger buttons to change the tape when requested to do so. 271 272#. Run Bareos, and backup a reasonably small directory, say 60 Megabytes. Do three successive backups of this directory. 273 274#. Stop Bareos, then restart it. Do another full backup of the same directory. Then stop and restart Bareos. 275 276#. Do a restore of the directory backed up, by entering the following restore command, being careful to restore it to an alternate location: 277 278 279 280 :: 281 282 restore select all done 283 yes 284 285 286 287 Do a diff on the restored directory to ensure it is identical to the original directory. If you are going to backup multiple different systems (Linux, Windows, Mac, Solaris, FreeBSD, ...), be sure you test the restore on each system type. 288 289#. If you have an autochanger, you should now go back to the btape program and run the autochanger test: 290 291 292 293 :: 294 295 btape /dev/nst0 296 auto 297 298 299 300 Adjust your autochanger as necessary to ensure that it works correctly. See the :ref:`Autochanger chapter <AutochangerTesting>` of this manual for a complete discussion of testing your autochanger. 301 302 303 304Autochanger 305----------- 306 307.. _AutochangerTesting: 308 309Testing Autochanger and Adapting mtx-changer script 310~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 311 312 313 314.. _section-MtxChangerManualUsage: 315 316 :index:`\ <single: Autochanger; Testing>`\ :index:`\ <single: Autochanger; mtx-changer>`\ :index:`\ <single: Command; mtx-changer>`\ :index:`\ <single: Problem; Autochanger>`\ :index:`\ <single: Problem; mtx-changer>`\ 317 318In case, Bareos does not work well with the Autochanger, it is preferable to "hand-test" that the changer works. To do so, we suggest you do the following commands: 319 320Make sure Bareos is not running. 321 322:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 list 0 /dev/nst0 0` 323 324:index:`\ <single: mtx-changer list>`\ 325 326This command should print: 327 328 329 330:: 331 332 1: 333 2: 334 3: 335 ... 336 337 338 339or one number per line for each slot that is occupied in your changer, and the number should be terminated by a colon (:). If your changer has barcodes, the barcode will follow the colon. If an error message is printed, you must resolve the problem (e.g. try a different SCSI control device name if /dev/sg0 is incorrect). For example, on FreeBSD systems, the autochanger SCSI control device is generally /dev/pass2. 340 341:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 listall 0 /dev/nst0 0` 342 343:index:`\ <single: mtx-changer listall>`\ 344 345This command should print: 346 347 348 349:: 350 351 Drive content: D:Drive num:F:Slot loaded:Volume Name 352 D:0:F:2:vol2 or D:Drive num:E 353 D:1:F:42:vol42 354 D:3:E 355 356 Slot content: 357 S:1:F:vol1 S:Slot num:F:Volume Name 358 S:2:E or S:Slot num:E 359 S:3:F:vol4 360 361 Import/Export tray slots: 362 I:10:F:vol10 I:Slot num:F:Volume Name 363 I:11:E or I:Slot num:E 364 I:12:F:vol40 365 366 367 368:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 transfer 1 2` 369 370:index:`\ <single: mtx-changer listall>`\ 371 372This command should transfer a volume from source (1) to destination (2) 373 374:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 slots` 375 376:index:`\ <single: mtx-changer slots>`\ 377 378This command should return the number of slots in your autochanger. 379 380:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 unload 1 /dev/nst0 0` 381 382:index:`\ <single: mtx-changer unload>`\ 383 384If a tape is loaded from slot 1, this should cause it to be unloaded. 385 386:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 load 3 /dev/nst0 0` 387 388:index:`\ <single: mtx-changer load>`\ 389 390Assuming you have a tape in slot 3, it will be loaded into drive (0). 391 392:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 loaded 0 /dev/nst0 0` 393 394:index:`\ <single: mtx-changer loaded>`\ 395 396It should print "3" Note, we have used an "illegal" slot number 0. In this case, it is simply ignored because the slot number is not used. However, it must be specified because the drive parameter at the end of the command is needed to select the correct drive. 397 398:command:`/usr/lib/bareos/scripts/mtx-changer /dev/sg0 unload 3 /dev/nst0 0` 399 400:index:`\ <single: mtx-changer unload>`\ 401 402will unload the tape into slot 3. 403 404Once all the above commands work correctly, assuming that you have the right Changer Command in your configuration, Bareos should be able to operate the changer. The only remaining area of problems will be if your autoloader needs some time to get the tape loaded after issuing the command. After the mtx-changer script returns, Bareos will immediately rewind and read the tape. If Bareos gets rewind I/O errors after a tape change, you will probably need to configure the 405:strong:`load_sleep` paramenter in the config file :file:`/etc/bareos/mtx-changer.conf`. You can test whether or not you need a sleep by putting the following commands into a file and running it as a script: 406 407 408 409:: 410 411 #!/bin/sh 412 /usr/lib/bareos/scripts/mtx-changer /dev/sg0 unload 1 /dev/nst0 0 413 /usr/lib/bareos/scripts/mtx-changer /dev/sg0 load 3 /dev/nst0 0 414 mt -f /dev/st0 rewind 415 mt -f /dev/st0 weof 416 417 418 419If the above script runs, you probably have no timing problems. If it does not run, start by putting a sleep 30 or possibly a sleep 60 in the script just after the mtx-changer load command. If that works, then you should configure the :strong:`load_sleep` paramenter in the config file :file:`/etc/bareos/mtx-changer.conf` to the specified value so that it will be effective when Bareos runs. 420 421A second problem that comes up with a small number of autochangers is that they need to have the cartridge ejected before it can be removed. If this is the case, the load 3 will never succeed regardless of how long you wait. If this seems to be your problem, you can insert an eject just after the unload so that the script looks like: 422 423 424 425:: 426 427 #!/bin/sh 428 /usr/lib/bareos/scripts/mtx-changer /dev/sg0 unload 1 /dev/nst0 0 429 mt -f /dev/st0 offline 430 /usr/lib/bareos/scripts/mtx-changer /dev/sg0 load 3 /dev/nst0 0 431 mt -f /dev/st0 rewind 432 mt -f /dev/st0 weof 433 434 435 436If this solves your problems, set the parameter :strong:`offline` in the config file :file:`/etc/bareos/mtx-changer.conf` to "1". 437 438Restore 439------- 440 441Restore a pruned job using a pattern 442~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 443 444:index:`\ <single: Restore; pruned job>`\ :index:`\ <single: Problem; Restore; pruned job>`\ :index:`\ <single: Regex>`\ 445 446It is possible to configure Bareos in a way, that job information are still stored in the Bareos catalog, while the individual file information are already pruned. 447 448If all File records are pruned from the catalog for a Job, normally Bareos can restore only all files saved. That is there is no way using the catalog to select individual files. With this new feature, Bareos will ask if you want to specify a Regex expression for extracting only a part of the full backup. 449 450:: 451 452 Building directory tree for JobId(s) 1,3 ... 453 There were no files inserted into the tree, so file selection 454 is not possible.Most likely your retention policy pruned the files 455 456 Do you want to restore all the files? (yes|no): no 457 458 Regexp matching files to restore? (empty to abort): /etc/.* 459 Bootstrap records written to /tmp/regress/working/zog4-dir.restore.1.bsr 460 461See also :ref:`FileRegex bsr option <FileRegex>` for more information. 462 463Problems Restoring Files 464~~~~~~~~~~~~~~~~~~~~~~~~ 465 466:index:`\ <single: Restore; Files; Problem>`\ :index:`\ <single: Problem; Restoring Files>`\ :index:`\ <single: Problem; Tape; fixed mode>`\ :index:`\ <single: Problem; Tape; variable mode>`\ 467 468The most frequent problems users have restoring files are error messages such as: 469 470 471 472:: 473 474 04-Jan 00:33 z217-sd: RestoreFiles.2005-01-04_00.31.04 Error: 475 block.c:868 Volume data error at 20:0! Short block of 512 bytes on 476 device /dev/tape discarded. 477 478 479 480or 481 482 483 484:: 485 486 04-Jan 00:33 z217-sd: RestoreFiles.2005-01-04_00.31.04 Error: 487 block.c:264 Volume data error at 20:0! Wanted ID: "BB02", got ".". 488 Buffer discarded. 489 490 491 492Both these kinds of messages indicate that you were probably running your tape drive in fixed block mode rather than variable block mode. Fixed block mode will work with any program that reads tapes sequentially such as tar, but Bareos repositions the tape on a block basis when restoring files because this will speed up the restore by orders of magnitude when only a few files are being restored. There are several ways that you can attempt to recover from this unfortunate situation. 493 494Try the following things, each separately, and reset your Device resource to what it is now after each individual test: 495 496#. Set "Block Positioning = no" in your Device resource and try the restore. This is a new directive and untested. 497 498#. Set "Minimum Block Size = 512" and "Maximum Block Size = 512" and try the restore. If you are able to determine the block size your drive was previously using, you should try that size if 512 does not work. This is a really horrible solution, and it is not at all recommended to continue backing up your data without correcting this condition. Please see the :ref:`TapeTestingChapter` section for more on this. 499 500#. Try editing the restore.bsr file at the Run xxx yes/mod/no prompt before starting the restore job and remove all the VolBlock statements. These are what causes Bareos to reposition the tape, and where problems occur if you have a fixed block size set for your drive. The VolFile commands also cause repositioning, but this will work regardless of the block size. 501 502#. Use bextract to extract the files you want – it reads the Volume sequentially if you use the include list feature, or if you use a .bsr file, but remove all the VolBlock statements after the .bsr file is created (at the Run yes/mod/no) prompt but before you start the restore. 503 504Restoring Files Can Be Slow 505~~~~~~~~~~~~~~~~~~~~~~~~~~~ 506 507:index:`\ <single: Restore; slow>`\ :index:`\ <single: Problem; Restore; slow>`\ 508 509Restoring files is generally much slower than backing them up for several reasons. The first is that during a backup the tape is normally already positioned and Bareos only needs to write. On the other hand, because restoring files is done so rarely, Bareos keeps only the start file and block on the tape for the whole job rather than on a file by file basis which would use quite a lot of space in the catalog. 510 511Bareos will forward space to the correct file mark on the tape for the Job, then forward space to the correct block, and finally sequentially read each record until it gets to the correct one(s) for the file or files you want to restore. Once the desired files are restored, Bareos will stop reading the tape. 512 513Finally, instead of just reading a file for backup, during the restore, Bareos must create the file, and the operating system must allocate disk space for the file as Bareos is restoring it. 514 515For all the above reasons the restore process is generally much slower than backing up (sometimes it takes three times as long). 516 517.. _section-RestoreCatalog: 518 519Restoring When Things Go Wrong 520~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 521 522:index:`\ <single: Catalog; Restore>`\ :index:`\ <single: Restore; Catalog>`\ :index:`\ <single: Disaster; Recovery; Catalog>`\ :index:`\ <single: Problem; Repair Catalog>`\ 523 524This and the following sections will try to present a few of the kinds of problems that can come up making restoring more difficult. We will try to provide a few ideas how to get out of these problem situations. In addition to what is presented here, there is more specific information on restoring a :ref:`Client <section-BareMetalRestoreClient>` and your :ref:`Server <section-RestoreServer>` in the :ref:`RescueChapter` chapter of this manual. 525 526Problem 527 My database is broken. 528 529Solution 530 For SQLite, use the vacuum command to try to fix the database. For either MySQL or PostgreSQL, see the vendor’s documentation. They have specific tools that check and repair databases, see the :ref:`CatMaintenanceChapter` sections of this manual for links to vendor information. 531 532 Assuming the above does not resolve the problem, you will need to restore or rebuild your catalog. Note, if it is a matter of some inconsistencies in the Bareos tables rather than a broken database, then running :ref:`bareos-dbcheck <bareos-dbcheck>` might help, but you will need to ensure that your database indexes are properly setup. 533 534Problem 535 How do I restore my catalog? 536 537Solution with a Catalog backup 538 If you have backed up your database nightly (as you should) and you have made a bootstrap file, you can immediately load back your database (or the ASCII SQL output). Make a copy of your current database, then re-initialize it, by running the following scripts: 539 540 :: 541 542 ./drop_bareos_tables 543 ./make_bareos_tables 544 545 After re-initializing the database, you should be able to run Bareos. If you now try to use the restore command, it will not work because the database will be empty. However, you can manually run a restore job and specify your bootstrap file. You do so by entering the run command in the console and selecting the restore job. If you are using the default bareos-dir.conf, this Job will be named RestoreFiles. Most likely it will prompt you with something such as: 546 547 548 549 :: 550 551 Run Restore job 552 JobName: RestoreFiles 553 Bootstrap: /home/user/bareos/working/restore.bsr 554 Where: /tmp/bareos-restores 555 Replace: always 556 FileSet: Full Set 557 Client: rufus-fd 558 Storage: File 559 When: 2005-07-10 17:33:40 560 Catalog: MyCatalog 561 Priority: 10 562 OK to run? (yes/mod/no): 563 564 565 566 A number of the items will be different in your case. What you want to do is: to use the mod option to change the Bootstrap to point to your saved bootstrap file; and to make sure all the other items such as Client, Storage, Catalog, and Where are correct. The FileSet is not used when you specify a bootstrap file. Once you have set all the correct values, run the Job and it will restore the backup of your database, which is most likely an ASCII dump. 567 568 You will then need to follow the instructions for your database type to recreate the database from the ASCII backup file. See the :ref:`Catalog Maintenance <CatMaintenanceChapter>` chapter of this manual for examples of the command needed to restore a database from an ASCII dump (they are shown in the Compacting Your XXX Database sections). 569 570 Also, please note that after you restore your database from an ASCII backup, you do NOT want to do a make_bareos_tables command, or you will probably erase your newly restored database tables. 571 572Solution with a Job listing 573 If you did save your database but did not make a bootstrap file, then recovering the database is more difficult. You will probably need to use :command:`bextract` to extract the backup copy. First you should locate the listing of the job report from the last catalog backup. It has important information that will allow you to quickly find your database file. For example, in the job report for the CatalogBackup shown below, the critical items are the Volume name(s), the Volume 574 Session Id and the Volume Session Time. If you know those, you can easily restore your Catalog. 575 576 577 578 :: 579 580 22-Apr 10:22 HeadMan: Start Backup JobId 7510, 581 Job=CatalogBackup.2005-04-22_01.10.0 582 22-Apr 10:23 HeadMan: Bareos 1.37.14 (21Apr05): 22-Apr-2005 10:23:06 583 JobId: 7510 584 Job: CatalogBackup.2005-04-22_01.10.00 585 Backup Level: Full 586 Client: Polymatou 587 FileSet: "CatalogFile" 2003-04-10 01:24:01 588 Pool: "Default" 589 Storage: "DLTDrive" 590 Start time: 22-Apr-2005 10:21:00 591 End time: 22-Apr-2005 10:23:06 592 FD Files Written: 1 593 SD Files Written: 1 594 FD Bytes Written: 210,739,395 595 SD Bytes Written: 210,739,521 596 Rate: 1672.5 KB/s 597 Software Compression: None 598 Volume name(s): DLT-22Apr05 599 Volume Session Id: 11 600 Volume Session Time: 1114075126 601 Last Volume Bytes: 1,428,240,465 602 Non-fatal FD errors: 0 603 SD Errors: 0 604 FD termination status: OK 605 SD termination status: OK 606 Termination: Backup OK 607 608 609 610 From the above information, you can manually create a bootstrap file, and then follow the instructions given above for restoring your database. A reconstructed bootstrap file for the above backup Job would look like the following: 611 612 613 614 :: 615 616 Volume="DLT-22Apr05" 617 VolSessionId=11 618 VolSessionTime=1114075126 619 FileIndex=1-1 620 621 622 623 Where we have inserted the Volume name, Volume Session Id, and Volume Session Time that correspond to the values in the job report. We’ve also used a FileIndex of one, which will always be the case providing that there was only one file backed up in the job. 624 625 The disadvantage of this bootstrap file compared to what is created when you ask for one to be written, is that there is no File and Block specified, so the restore code must search all data in the Volume to find the requested file. A fully specified bootstrap file would have the File and Blocks specified as follows: 626 627 628 629 :: 630 631 Volume="DLT-22Apr05" 632 VolSessionId=11 633 VolSessionTime=1114075126 634 VolFile=118-118 635 VolBlock=0-4053 636 FileIndex=1-1 637 638 639 640 Once you have restored the ASCII dump of the database, you will then to follow the instructions for your database type to recreate the database from the ASCII backup file. See the :ref:`Catalog Maintenance <CatMaintenanceChapter>` chapter of this manual for examples of the command needed to restore a database from an ASCII dump (they are shown in the Compacting Your XXX Database sections). 641 642 Also, please note that after you restore your database from an ASCII backup, you do NOT want to do a make_bareos_tables command, or you will probably erase your newly restored database tables. 643 644Solution without a Job Listing 645 If you do not have a job listing, then it is a bit more difficult. Either you use the :ref:`bscan <bscan>` program to scan the contents of your tape into a database, which can be very time consuming depending on the size of the tape, or you can use the :ref:`bls <bls>` program to list everything on the tape, and reconstruct a bootstrap file from the bls listing for the file or files you want following the instructions given above. 646 647 There is a specific example of how to use bls below. 648 649Problem 650 Trying to restore the last known good full backup by specifying item 3 on the restore menu then the JobId to restore, but Bareos then reports: 651 652 653 654 :: 655 656 1 Job 0 Files 657 658 659 660 and restores nothing. 661 662Solution 663 Most likely the File records were pruned from the database either due to the File Retention period expiring or by explicitly purging the Job. By using the "llist jobid=nn" command, you can obtain all the important information about the job: 664 665 666 667 :: 668 669 llist jobid=120 670 JobId: 120 671 Job: save.2005-12-05_18.27.33 672 Job.Name: save 673 PurgedFiles: 0 674 Type: B 675 Level: F 676 Job.ClientId: 1 677 Client.Name: Rufus 678 JobStatus: T 679 SchedTime: 2005-12-05 18:27:32 680 StartTime: 2005-12-05 18:27:35 681 EndTime: 2005-12-05 18:27:37 682 JobTDate: 1133803657 683 VolSessionId: 1 684 VolSessionTime: 1133803624 685 JobFiles: 236 686 JobErrors: 0 687 JobMissingFiles: 0 688 Job.PoolId: 4 689 Pool.Name: Full 690 Job.FileSetId: 1 691 FileSet.FileSet: BackupSet 692 693 694 695 Then you can find the Volume(s) used by doing: 696 697 698 699 :: 700 701 sql 702 select VolumeName from JobMedia,Media where JobId=1 and JobMedia.MediaId=Media.MediaId; 703 704 705 706 Finally, you can create a bootstrap file as described in the previous problem above using this information. 707 708 Bareos will ask you if you would like to restore all the files in the job, and it will collect the above information and write the bootstrap file for you. 709 710Problem 711 You don’t have a bootstrap file, and you don’t have the Job report for the backup of your database, but you did backup the database, and you know the Volume to which it was backed up. 712 713Solution 714 Either :command:`bscan` the tape (see below for bscanning), or better use :command:`bls` to find where it is on the tape, then use :command:`bextract` to restore the database. For example, 715 716 717 718 :: 719 720 ./bls -j -V DLT-22Apr05 /dev/nst0 721 722 723 724 Might produce the following output: 725 726 :: 727 728 bls: butil.c:258 Using device: "/dev/nst0" for reading. 729 21-Jul 18:34 bls: Ready to read from volume "DLT-22Apr05" on device "DLTDrive" 730 (/dev/nst0). 731 Volume Record: File:blk=0:0 SessId=11 SessTime=1114075126 JobId=0 DataLen=164 732 ... 733 Begin Job Session Record: File:blk=118:0 SessId=11 SessTime=1114075126 734 JobId=7510 735 Job=CatalogBackup.2005-04-22_01.10.0 Date=22-Apr-2005 10:21:00 Level=F Type=B 736 End Job Session Record: File:blk=118:4053 SessId=11 SessTime=1114075126 737 JobId=7510 738 Date=22-Apr-2005 10:23:06 Level=F Type=B Files=1 Bytes=210,739,395 Errors=0 739 Status=T 740 ... 741 21-Jul 18:34 bls: End of Volume at file 201 on device "DLTDrive" (/dev/nst0), 742 Volume "DLT-22Apr05" 743 21-Jul 18:34 bls: End of all volumes. 744 745 746 747 Of course, there will be many more records printed, but we have indicated the essential lines of output. From the information on the Begin Job and End Job Session Records, you can reconstruct a bootstrap file such as the one shown above. 748 749Problem 750 How can I find where a file is stored? 751 752Solution 753 Normally, it is not necessary, you just use the restore command to restore the most recently saved version (menu option 5), or a version saved before a given date (menu option 8). If you know the JobId of the job in which it was saved, you can use menu option 3 to enter that JobId. 754 755 If you would like to know the JobId where a file was saved, select restore menu option 2. 756 757 You can also use the query command to find information such as: 758 759 :: 760 761 *query 762 Available queries: 763 1: List up to 20 places where a File is saved regardless of the 764 directory 765 2: List where the most recent copies of a file are saved 766 3: List last 20 Full Backups for a Client 767 4: List all backups for a Client after a specified time 768 5: List all backups for a Client 769 6: List Volume Attributes for a selected Volume 770 7: List Volumes used by selected JobId 771 8: List Volumes to Restore All Files 772 9: List Pool Attributes for a selected Pool 773 10: List total files/bytes by Job 774 11: List total files/bytes by Volume 775 12: List Files for a selected JobId 776 13: List Jobs stored on a selected MediaId 777 14: List Jobs stored for a given Volume name 778 15: List Volumes Bareos thinks are in changer 779 16: List Volumes likely to need replacement from age or errors 780 Choose a query (1-16): 781 782 783 784Problem 785 I didn’t backup my database. What do I do now? 786 787Solution 788 This is probably the worst of all cases, and you will probably have to re-create your database from scratch and then bscan in all your volumes, which is a very long, painful, and inexact process. 789 790 There are basically three steps to take: 791 792 #. Ensure that your SQL server is running (MySQL or PostgreSQL) and that the Bareos database (normally bareos) exists. See the :ref:`section-CreateDatabase` chapter of the manual. 793 794 #. Ensure that the Bareos databases are created. This is also described at the above link. 795 796 #. Start and stop the Bareos Director using the propriate bareos-dir.conf file so that it can create the Client and Storage records which are not stored on the Volumes. Without these records, scanning is unable to connect the Job records to the proper client. 797 798 When the above is complete, you can begin bscanning your Volumes. Please see the :ref:`bscan` chapter for more details. 799 800 801 802 803 804 805