Backup & Recovery: Inexpensive Backup Solutions for Open Systems
6.3. An Example Configuration
The best way to illustrate how Bacula is used is to show you an extended example. The example network shown in Figure 6-3 incorporates three machines: an Intel Linux system running the Bacula server components, a Windows XP client, and a Mac OS X client. For simplicity's sake, they are connected to the same network segment, but as long as IP connectivity is available between the server and the clients, this is not a requirement. Figure 6-3. Example Bacula configuration
This example configures a recent Bacula distribution (at least version 1.38.2, so that we get Windows VSS support and Mac OS X resource fork support) on the Linux system and configures the Linux server to back up some of its own files. Once we have that working, we'll install and configure the Windows client and the Macintosh client and back up directories on each of them. In our sample configuration, we'll back up /etc on the Linux system, using a directory on the server as our storage device rather than tape or optical media. 6.3.1. Setting Up the Server
To install the Bacula application, we'll use RPMs provided by http://www.bacula.org, which can be installed using standard Linux system management techniques and tools. The packages install the Bacula configuration files for Linux in /etc/bacula, as mandated by the Linux Standard Base (LSB). For ease of installation, we'll use the SQLite database (in a production network, you would use MySQL or PostgreSQL).
For our simple example, just rename the default client ID of Client1 to test1, and define a FileSet resource using the following line: File = /etc
The following line is needed in the default pool definition to tell Bacula to create new sequentially numbered volumes as it requires them: Label Format = TestVol The other supplied defaults are suitable for most small configurations. Configuring the storage daemon is just as easy; again, relying on Bacula to supply sane default settings, use the FileStorage storage resource, pointing it to /opt/backups (owned by the bacula user) rather than to /tmp; ensure that Label Media = yes is set; and make sure that the passwords agree for the director, file daemon, and storage daemon. Following these updates, restart the Bacula services using the /etc/init.d scripts installed with the package, and run the Bacula bconsole to test the installation. 6.3.2. Initial Backup (Linux Client)
Once the Bacula console initializes, use the supplied job definitions to initiate a backup job (test1 is the job we created with the settings shown earlier): *run A job name must be specified. The defined Job resources are: 1: test1 2: BackupCatalog 3: RestoreFiles Select Job resource (1-3): 1 Run Backup job JobName: test1 FileSet: Etc Level: Incremental Client: test1-fd Storage: File Pool: Default When: 2006-01-20 09:30:38 Priority: 10 OK to run? (yes/mod/no): yes Job started. JobId=4 After a while, the console says: You have messages.
Here are the messages: *messages [ ... lines detailing automatic creation/labeling of volume omitted ... ] JobId: 4 Job: test1.2006-01-20_09.30.39 Backup Level: Full (upgraded from Incremental) Client: "test1-fd" i686-redhat-linux-gnu,redhat,(Heidelberg) FileSet: "Etc" 2006-01-19 10:47:39 Pool: "Default" Storage: "File" [ ... lines omitted ... ] FD Bytes Written: 40,129,258 SD Bytes Written: 40,656,235 [ ... lines omitted ... ] Termination: Backup OK
This response shows that the backup succeeded and backed up about 40 MB. A full backup was actually performed even though we specified an incremental backup (because no full backup had been performed yet).
6.3.3. Initial Restore (Linux Client)
To test the backup, we'll restore a file. Choosing the file /etc/protocols at random, use bconsole's restore command to initiate the restore. From bconsole, enter the restore command, select option 7 to enter a list of files, select a client, enter the file to be restored, and press Enter. Now, we'll verify that the file protocols is present in /tmp/bacula-restores/etc/protocols. Although it is possible to restore files in place, Bacula's default configuration restores them under /tmp/bacula-restores to allow you to verify that the restored files are correct before committing them to their actual locations in the filesystem. 6.3.4. Windows Backup
Next let's back up some files on the Windows workstation. First, use a text editor to define a new Job, FileSet, and Client in bacula-dir.conf: Job { Name = "WinXP-test" Client = winxp-fd JobDefs = "DefaultJob" FileSet = "WinTest" } FileSet { Name = "WinTest" Enable VSS = yes Include { [ ... lines omitted ... ] File = C:/Windows/SYSTEM32/DRIVERS/ETC File = "C:/Program Files/Wizards/eTools/User" } [ ... lines omitted ... ] } # Client (File Services) to backup Client { Name = winxp-fd Address = vpc-xp2.fsf.net ... }
The important points to notice here are Enable VSS = yes in the FileSet resource, which turns on VSS in Windows, and the format of the FileSet resource. Windows files are specified with forward slashes, and, if the filename contains spaces, it must be enclosed in double quotes. Use the reload command in the console to enable the director to pick up changes to its configuration files. Next, install the Bacula Windows client on the Windows workstation. It is a standard Windows package, installed like any other Windows application. The configuration files require editing to reflect the director (test1-dir) and its password. Once installed, the file daemon runs as a Windows service, and a little icon of a cassette tape appears in the Windows tray as described earlier. Running the wx-console command in the Bacula install directory displays a screen like that shown in Figure 6-4. Figure 6-4. wx-console
Running a backup job is very similar to running one for the Linux client, except that we'll run the WinXP-test Job rather than test1. The director logs look almost identical to the earlier backup: 20-Jan 14:49 winxp-fd: Generate VSS snapshots. Driver="VSS WinXP", Drive(s)="C" [ ... lines omitted ... ] Termination: Backup OK
Let's try something a bit different for the file restore, restoring this file: C:\Program Files\Wizards\eTools\User\Characters\lola13.chr
Rather than enter a list of files, let's choose the option to restore the most recent backup for our Windows client, and use bconsole rather than wx-console for this job. bconsole shows a directory listing interface; navigate with cd and choose the file to restore with the mark command (with wx-console, you navigate the directory tree with the mouse and click on filenames to mark them). Running the restore job once again puts the file under /tmp/bacula-restores, which is translated to C:\tmp\bacula-restores in the Windows filesystem. From there, it can be copied back into place. 6.3.5. Mac OS X Backup
Mac OS X is really BSD Unix under the hood, so it should not be surprising that Bacula behaves on it very much as it does on any other Unix or Linux machine. Configuring the director is basically the same as adding the Windows client. However, in the FileSet resource, you add this directive: HFS Plus Support = yes
This option, which enables proper backing up of resource forks, should always be specified for Mac OS X clients. For this example, let's specify the following directory to back up: File = "/Users/adam/Documents/Emulators/Virtual II"
We chose this directory because it contains an application bundle. Macintosh applications are actually directory structures containing not only the binary executable, but resources and support files. If the application is to run successfully, the entire structure, including any associated resource forks, must be maintained. The backup process is identical to backing up any other client, and its output looks exactly the same. After backing up that directory, remove it entirely, deleting the Virtual II application. When we run the restore job this time, we'll use the restore all command; this is equivalent to marking all files in the tree in our Windows example (but obviously a great deal faster). As a result, the restore job restores the entire directory under /tmp/bacula-restores. After moving the directory back to its correct location, the Virtual II application runs without incident. This example demonstrates backup and restore for three different clients: Linux, Windows XP, and Mac OS X. All three are very similar in use; the primary difference in command usage is not system-specific, but simply has to do with which restore option is chosen: single named file restore, marking files in a filesystem tree, or restoring an entire tree. On the server side, we need a single line of configuration for each non-Linux client to preserve unique filesystem features: VSS support for Windows and HFS+ support for Mac OS X. The default method of file restoration is to restore the files under /tmp/bacula-restores (the default) and then copy them to their final destinations once you are sure that you have restored the right files in their correct versions. Once familiar with Bacula's operation, many users choose to restore files directly to their original locations. |
Категории