====== 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/05 23:50] fishy Start of database-server-backup, including the Catalog. |
guides:bacup:bacula [2010/11/06 16:28] (current) fishy Untested change to the Windows FileSet. |
||
---|---|---|---|
Line 588: | Line 588: | ||
# WorkingDirectory for the File Daemon. | # WorkingDirectory for the File Daemon. | ||
File = /var/lib/bacula | File = /var/lib/bacula | ||
+ | |||
+ | # For mysql servers, it is better to dump and restore | ||
+ | # and/or do binlog replay. So, instead of dumping the | ||
+ | # MySQL data directory, do dull database dumps to | ||
+ | # a different location, and use binlogs in addition if | ||
+ | # real incremental MySQL backups are needed/wanted. | ||
+ | File = /var/lib/mysql | ||
+ | |||
# Excluding files/directories that do not exist | # Excluding files/directories that do not exist | ||
# has no effect other than making the FileSet generic.. | # has no effect other than making the FileSet generic.. | ||
Line 1035: | 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 1063: | 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 1179: | 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 ===== |