From 76409340c09541cafc56fdbdebf16135952fd7f2 Mon Sep 17 00:00:00 2001 From: Thomas Glatthor Date: Mon, 18 Aug 2008 08:37:08 +0000 Subject: [PATCH] \bf{xxx} => {\bf xxx} --- docs/manuals/de/concepts/newfeatures.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/manuals/de/concepts/newfeatures.tex b/docs/manuals/de/concepts/newfeatures.tex index e954e91f..8f7b3cf0 100644 --- a/docs/manuals/de/concepts/newfeatures.tex +++ b/docs/manuals/de/concepts/newfeatures.tex @@ -21,12 +21,12 @@ writing it to a volume in a different pool. In some respects the Vbackup feature works similar to a Migration job, in that Bacula normally reads the data from the pool specified in the -Job resource, and writes it to the \bf{Next Pool} specified in the +Job resource, and writes it to the {\bf Next Pool} specified in the Job resource. The input Storage resource and the Output Storage resource must be different. The Vbackup is enabled on a Job by Job in the Job resource by specifying -a level of \bf{VirtualFull}. +a level of {\bf VirtualFull}. A typical Job resource definition might look like the following: @@ -96,7 +96,7 @@ run job=MyBackup level=Incremental So providing there were changes between each of those jobs, you would end up with a Full backup, a Differential, which includes the first Incremental backup, then two -Incremental backups. All the above jobs would be written to the \bf{Default} pool. +Incremental backups. All the above jobs would be written to the {\bf Default} pool. To consolidate those backups into a new Full backup, you would run the following: @@ -105,7 +105,7 @@ run job=MyBackup level=VirtualFull \end{verbatim} And it would produce a new Full backup without using the client, and the output would -be written to the \bf{Full} Pool which uses the Diskchanger Storage. +be written to the {\bf Full} Pool which uses the Diskchanger Storage. -- 2.39.5