... | ... | @@ -4,8 +4,7 @@ title: Backup and restore procedures |
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
Tutorial
|
|
|
========
|
|
|
# Tutorial
|
|
|
|
|
|
Most work on Bacula happens on the **director**, which is where
|
|
|
backups are coordinated. Actual data is stored on the **storage
|
... | ... | @@ -73,8 +72,7 @@ Here we see that no backups are running, and the last ones succeeded correctly. |
|
|
You can also check the status of individual clients with `status
|
|
|
client`.
|
|
|
|
|
|
Checking messages
|
|
|
-----------------
|
|
|
## Checking messages
|
|
|
|
|
|
The `messages` command shows the latest messages on the
|
|
|
`bconsole`. It's useful to run this command when you start your
|
... | ... | @@ -82,8 +80,7 @@ session as it will flush the (usually quite long) buffer of |
|
|
messages. That way the next time you call the command, you will only
|
|
|
see the result of your latest jobs.
|
|
|
|
|
|
Running a backup
|
|
|
----------------
|
|
|
## Running a backup
|
|
|
|
|
|
Backups are ran regularly by a cron job, but if you need to run a
|
|
|
backup immediately, this can be done in the `bconsole`.
|
... | ... | @@ -147,14 +144,12 @@ Longer version: |
|
|
That's it, new files were sucked in and you're good to do whatever
|
|
|
nasty things you were about to do.
|
|
|
|
|
|
How to...
|
|
|
==========
|
|
|
# How-to
|
|
|
|
|
|
This section is more in-depths and will explain more concepts as we
|
|
|
go. Relax, take a deep breath, it should go fine.
|
|
|
|
|
|
Configure backups on new machines
|
|
|
---------------------------------
|
|
|
## Configure backups on new machines
|
|
|
|
|
|
Backups for new machines should be automatically configured by Puppet
|
|
|
using the `bacula::client` class, included everywhere (through
|
... | ... | @@ -163,8 +158,7 @@ using the `bacula::client` class, included everywhere (through |
|
|
There are special configurations required for MySQL and PostgreSQL
|
|
|
databases, see the design section for more information on those.
|
|
|
|
|
|
Restore files
|
|
|
-------------
|
|
|
## Restore files
|
|
|
|
|
|
Short version:
|
|
|
|
... | ... | @@ -408,8 +402,7 @@ Once the job is done, the files will be present in the chosen location |
|
|
See the [upstream manual](https://www.bacula.org/9.4.x-manuals/en/main/Restore_Command.html) more information about the [restore
|
|
|
command](https://www.bacula.org/9.4.x-manuals/en/main/Restore_Command.html).
|
|
|
|
|
|
Restore a host that has been offline for a long time
|
|
|
----------------------------------------------------
|
|
|
## Restore a host that has been offline for a long time
|
|
|
|
|
|
If a host has been offline for a long time its storage configuration might have been expired by puppet. You will notice that when you are trying to restore some file to a different host you will get the following error after having selected the files:
|
|
|
```
|
... | ... | @@ -483,9 +476,7 @@ service bacula-director restart |
|
|
|
|
|
Go ahead with the restore procedure, it should work now.
|
|
|
|
|
|
|
|
|
Restore the directory server
|
|
|
----------------------------
|
|
|
## Restore the directory server
|
|
|
|
|
|
If the storage daemon disappears catastrophically, there's nothing we
|
|
|
can do: the data is lost. But if the *director* disappears, we can
|
... | ... | @@ -724,8 +715,7 @@ If the director takes a long time to start and ultimately fails with: |
|
|
|
|
|
It's because you forgot to reset the director password, in step 9.
|
|
|
|
|
|
Get files without a director
|
|
|
----------------------------
|
|
|
## Get files without a director
|
|
|
|
|
|
If you want to get to files stored on the bacula storgage host without
|
|
|
involving the director, they can be accessed directly as well. Remember
|
... | ... | @@ -757,13 +747,11 @@ put their names into a file such as `include` and call bextract with `-i`: |
|
|
|
|
|
bextract -i ~/include /srv/backups/bacula/dictyotum.torproject.org/torproject-inc-dictyotum.torproject.org.2019-09-25_11:53 /var/tmp/restore
|
|
|
|
|
|
Restore PostgreSQL databases
|
|
|
----------------------------
|
|
|
## Restore PostgreSQL databases
|
|
|
|
|
|
See [howto/postgresql](howto/postgresql) for restore instructions on PostgreSQL databases.
|
|
|
|
|
|
Restore MySQL databases
|
|
|
-----------------------
|
|
|
## Restore MySQL databases
|
|
|
|
|
|
MySQL restoration should be fairly straightforward. Install MySQL:
|
|
|
|
... | ... | @@ -775,14 +763,12 @@ Load each database dump: |
|
|
mysql < /var/backups/local/mysql/$dump
|
|
|
done
|
|
|
|
|
|
Restore LDAP databases
|
|
|
----------------------
|
|
|
## Restore LDAP databases
|
|
|
|
|
|
See [howto/ldap](howto/ldap) for LDAP-specific procedures.
|
|
|
|
|
|
|
|
|
Monitoring warnings
|
|
|
-------------------
|
|
|
## Monitoring warnings
|
|
|
|
|
|
Hint: see also the [howto/postgresql](howto/postgresql) documentation for the backup
|
|
|
procedures specific to that database.
|
... | ... | @@ -847,8 +833,7 @@ that the rescheduled backup will eventually go through. The duplicate |
|
|
job is also fine: worst case there is it will just run after the first
|
|
|
one does, resulting in a bit more I/O than we'd like.
|
|
|
|
|
|
Design
|
|
|
======
|
|
|
# Design
|
|
|
|
|
|
This section documents how backups are setup at Tor. It should be
|
|
|
useful if you wish to recreate or understand the architecture.
|
... | ... | @@ -915,8 +900,7 @@ Those both point to the same file, inode 1184448. |
|
|
|
|
|
Those backups then get included in the normal Bacula backups.
|
|
|
|
|
|
References
|
|
|
==========
|
|
|
# References
|
|
|
|
|
|
* [upstream manual](https://www.bacula.org/9.4.x-manuals/en/main/index.html) (has formatting problems, the [PDF](https://www.bacula.org/9.4.x-manuals/en/main/main.pdf) looks better)
|
|
|
* [console command manual](https://www.bacula.org/9.4.x-manuals/en/console/Bacula_Console.html) ([PDF](http://www.bacula.org/9.4.x-manuals/en/console/console.pdf))
|
... | ... | |