====== Sitemap ====== This is a sitemap over all available pages ordered by [[doku>namespaces|namespaces]].
Page Actions
Wiki Actions
User Actions
====== Differences ====== This shows you the differences between two versions of the page.
|
guides:bacup:bacula [2010/11/06 00:33] fishy Changed the default FileSet to account for MySQL servers. |
guides:bacup:bacula [2010/11/06 16:28] (current) fishy Untested change to the Windows FileSet. |
||
|---|---|---|---|
| Line 1043: | Line 1043: | ||
| WildFile = "[A-Z]:/pagefile.sys" | WildFile = "[A-Z]:/pagefile.sys" | ||
| + | # bacula-fd > 3.0 on win32/64 should be able to use VSS, | ||
| + | # so we want to avoid copying the VSS metadata during the backup | ||
| + | File = "\"C:/System Volume Information\"" | ||
| + | |||
| # Bacula working directory | # Bacula working directory | ||
| WildFile = "C:/Program Files/Bacula/working/*" | WildFile = "C:/Program Files/Bacula/working/*" | ||
| Line 1071: | Line 1075: | ||
| } | } | ||
| </code> | </code> | ||
| + | |||
| + | A word of caution. My Windows client normally runs F-Secure antivirus. With its realtime scanner active, my backups were crazy slow (<600kbit/sec) making my backups take forever. Disabling the scanner boosted the speed up to normal speeds. I am investigating ways to either "white-list" the bacula-fd process from the scanner, or temporarily disabling it during backups. | ||
| Use a bconsole to reload the configuration, and test it by running an ''estimate''. And that is all there is to it. Windows-clients are really not that different from Unix clients :) | Use a bconsole to reload the configuration, and test it by running an ''estimate''. And that is all there is to it. Windows-clients are really not that different from Unix clients :) | ||
| Line 1187: | Line 1193: | ||
| Client definition like usual. | Client definition like usual. | ||
| - | FIXME The rest of this content will be arriving shortly. | + | <code> |
| + | Client { | ||
| + | Name = database.example.com; | ||
| + | Address = database.example.com; | ||
| + | FDPort = 9102; | ||
| + | Catalog = StandardCatalog; | ||
| + | Password = "random-password-for-fd-director"; | ||
| + | AutoPrune = yes; | ||
| + | } | ||
| + | </code> | ||
| + | |||
| + | What is more interesting, is the one line added to the Job definition: | ||
| + | |||
| + | <code> | ||
| + | Job { | ||
| + | Name = "database.example.com Default" | ||
| + | FileSet = "Full Set" | ||
| + | JobDefs = "DefaultJob"; | ||
| + | Client = database.example.com; | ||
| + | |||
| + | Client Run Before Job = "/etc/bacula/scripts/mysqldump.sh %l"; | ||
| + | |||
| + | Write Bootstrap = "/var/lib/bacula/bactank.bsr"; | ||
| + | } | ||
| + | </code> | ||
| + | |||
| + | There are several ways to run scripts/programs from the Job definition | ||
| + | * **RunScript** A section-definition for scripts to run on the **Director** | ||
| + | * **Run Before Job** Path and arguments to a script to run on the **Director** before the data-part of the Job is started. | ||
| + | * **Run After Job** Path and arguments to a script to run on the **Director** after the data-part of the Job is done | ||
| + | * **Client Run Before Job** Path and arguments to a script to run on the **Client** before the data-part of the Job is started. | ||
| + | * **Client Run After Job** Path and arguments to a script to run on the **Client** after the data-part of the Job is done | ||
| + | * **Run After Failed Job** Path and arguments to a script to run on the **Director** after a Job is detected as Failed. | ||
| + | |||
| + | To these scripts, there are several variables that can be used as arguments with the commands. Most importantly for Client Pre commands: | ||
| + | <code> | ||
| + | %% = % | ||
| + | %c = Client's name | ||
| + | %d = Director's name | ||
| + | %i = JobId | ||
| + | %j = Unique Job id | ||
| + | %l = Job Level | ||
| + | %n = Job name | ||
| + | %s = Since time | ||
| + | %t = Job type (Backup, ...) | ||
| + | </code> | ||
| + | |||
| + | As seen in my Job definition, after running the Client-Run-Before script, the rest of the Job is simply doing a file-based backup. | ||
| + | |||
| + | If you remember the "Full Set" FileSet, I have Excluded ''/var/lib/mysql'' from the FileSet. This means that for a full Restore of this database server, I will have to start the Restore by pulling in the last Full, then merging inn a Differential if that has run after the Full. After that, I will have to reinstall the MySQL server, tank in the SQL files from ''/var/local/backups''. Finally, to get the database up to the latest increment, I'll have to replay all needed log-files. | ||
| + | |||
| + | Documentation related to the pre- and post-scripts are located in the [[http://bacula.org/5.0.x-manuals/en/main/main/Configuring_Director.html#SECTION001830000000000000000|Job definition documentation]] | ||
| ===== Links, references, scratch ===== | ===== Links, references, scratch ===== | ||