Bacula Windows client ( Установка и настройка Windows клиента Bacula. )

12 ноября 2010 (обновлено 15 августа 2016)

OS: MS Windows Server 2003/2008.
Application: Bacula v.2.4/v.5.2.

В репозитории «Debian Lenny» Bacula версии 2.4, а для «Debian Squeeze» Bacula версии 5.2. Думаю, что для гарантированной совместимости клиента для Windows лучше подобрать такой же версии, что и сам сервер резервирования.

Идём на сайт Bacula, http://www.bacula.org/
Переходим в раздел Download, но не текущего релиза, а в репозиторий SourceForge, http://sourceforge.net/projects/bacula/files/#files
Качаем winbacula-2.4 для «Debian Lenny» или bacula-win-5.2 для «Debian Squeeze».

Запускаем инсталлятор. Выбираем ручной режим выбора компонентов. Выбираем для установки только «Client» — «File Service».
Указываем в окне запроса уникальное FQDN имя клиента, порт для подключения «9102», количество одновременных соединений с клиентом «2» (одно для резервирования и одно для проверки статуса) и пароль для подключения. Естественно, устанавливаем клиента Bacula как системный «сервис».

После указания параметров клиента установщик запросит имя «Директора» и реквизиты подключения «монитора» состояния. Первое указываем, а вот поля реквизитов монитора я очистил за ненадобностью.

Конфигурационный файл клиента Bacula расположился в директории «C:\\Documents and Settings\\All Users\\Application Data\\Bacula». Считаю полезным подчистить его и оставить только те описания, что действительно необходимы. Что-то вроде следующего:

FileDaemon <
# Произвольное уникальное имя клиента (лучше, чтобы оно совпадало с FQDN клиента)
Name = windows0.domainn.local
FDport = 9102
WorkingDirectory = «C:\\Documents and Settings\\All Users\\Application Data\\Bacula\\Work»
Pid Directory = «C:\\Documents and Settings\\All Users\\Application Data\\Bacula\\Work»
Maximum Concurrent Jobs = 2
>

Director <
Name = dir0.backup.local
Password = «strongPasswordForClient»
>

Messages <
Name = Standard
director = dir0.backup.local = all, !skipped, !restored
>

Перезапускаем (или запускаем) сервис клиента Bacula. Необходимо пройти в графическую консоль «Управление компьютером» => «Службы» и запустить «Bacula File Service».

Клиент, кстати, запускается в качестве службы достаточно просто, достаточно указать соответствующую опцию:

Отключить функционал запуска клиента в качестве службы не сложнее:

Конфигурирование клиента на стороне сервера ни чем особенным не отличается от варианта для Linux, разве что пути в описании резервируемой области указываем в формате Windows:

.
FileSet <
Name = «file-set-windows0.domain.local»

# Отключаем использование механизма «теневого копирования», всё равно он нам не нужен для простого резервирования
Enable VSS = no

Include <
Options <
.
# Указываем игнорировать регистр имён файлов и директорий (директива исключительно для Win32)
Ignore Case = yes
>
.
File = «C:/lotus»
.

Не забываем проверять корректность конфигурации средствами самого Bacula:

[ уже посетило: 20707 / +9 / -4 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Установка клиента Bacula для Linux и Windows

Клиент Bacula не обладает большим количеством зависимостей, и разработан на базе C / C++, поэтому его установщики могут быть скомпилированы под практически любую операционную систему. Необходимо помнить, что версия Клиента не может быть больше размером, чем процесс управления или процесс хранения, однако обратная ситуация вполне может возникнуть.

Далее мы рассмотрим некоторые варианты установки клиента.

Установка клиента на Linux

Bacula.org и корпоративные пакеты сообщества

Здесь есть два варианта установки. Мы можем опять зарегистрировать репозитории yum/apt для установки Клиента (по такому же принципу, как и при установке Сервера), что подразумевает обновления в будущем, или мы можем скачать и установить пакеты вручную.

Метод с репозиториями

Зарегистрируйте репозитории Bacula.org или Bacula Systems (Enterprise).

Установка базы данных или пакета Директора Bacula необязательна. Продолжайте установку, используя только Клиентский пакет. Например:

Далее проследуйте в раздел настройки клиента.

Загрузка пакетов вручную

Используйте веб-браузер для доступа к репозиторию и найдите необходимые пакеты: bacula-client и libs для семейства CentOS / RHEL, bacula-client и common — для Debian / Ubuntu.

Скачайте и установите, как указано в примере:

Если вы используете CentOS и/или располагаете работающим фаерволлом — отключите Selinux для открытия доступа к порту 9102 в фаерволле:

Далее проследуйте в раздел настройки клиента.

Установка клиента для Windows

Для этого существуют уже собранные пакеты на вебсайте Bacula.org. Они содержат Клиент, процесс Хранения и bconsole / BAT console для Windows, но конкретно в этом случае мы устанавливаем только Клиент, так как это более реалистично если речь идет о бэкапе серверов производства.

• Скачайте и распакуйте клиентские пакеты с Bacula.org: https://blog.bacula.org/binary-download-center/ (или корпоративный репозиторий Bacula Systems)
• Запустите файл Setup с правами Администратора (Системы и Домена, если возможно). Примите лицензионное соглашение.
• Выберите тот .exe файл, который подходит под вашу архитектуру Windows: 32 bit или 64 bit. Например: bacula-win64-9.4.0.exe.
• Запустите этот файл и примите условия лицензионного соглашения.
• Как показано ниже, выберите Custom Setup (позволяет вам настроить клиент, включая имя Директора, и возможность скопировать сгенерированный случайный пароль для последующих взаимодействий с бэкап-сервером).

• Далее вам предстоит выбрать части программы, которые вы хотите установить, как показано ниже (в этом случае выбраны клиент для Windows и соответствующие бесплатные плагины).

• Следующим шагом станет возможность изменить имя клиента Bacula и пароль для Директорского доступа к устанавливаемому клиенту. Скопируйте этот пароль, затем продолжайте.

• И наконец, введите имя Директора так же, как указано на вашей основной машине-сервере (bacula-dir-conf — Director resource). Эту информацию также можно получить, открыв bconsole или используя команду version.

• Дождитесь окончания установки. Закройте все последующие всплывающие окна.
• Переходите к разделу настройки клиента Bacula.

Настройка клиента Bacula

I. bacula-fd.conf (сторона-клиент):

• Отредактируйте файл конфигурации клиента:
  • Linux: vi /etc/bacula/bacula-fd.conf
  • Windows: если вы этого не сделали в процессе установки, то: Menu> Bacula> Configuration> Edit Client Configuration

• Проверьте, чтобы имя Директора было указано точно так же, как и на вашем сервере-Директоре (bacula-dir.conf — Director resource, или через bconsole и команду version), отредактируйте его при необходимости.
• Вставьте ранее скопированный сгенерированный пароль в ту же самую директорию — bacula-fd.conf (раздел для пароля) или измените по желанию. Эта информация потребуется вам далее для привязки клиента к Директору.
• Измените имя у FileDaemon, если необходимо.
• Сохраните и выйдите из клиента. Перезапустите клиентский процесс:
  • Linux:/etc/init.d/bacula-fd restart
  • Windows: Откройте менеджер сервисов (services.msc) и перезапустите сервис Bacula File Daemon
• Проверьте наличие у системы активного фаерволла. Если он имеется, добавьте входящее исключение TCP 9102 для открытия доступа Директора к клиенту. Альтернатива — введите следующую команду в терминале Windows:

II. bacula-dir.conf (сторона-сервер):

• Добавьте нового клиента как ресурс (скопируйте данные уже существующего клиента с изменением в необходимых местах. Это также можно сделать в BWeb если речь идет о корпоративном клиенте). Измените имя клиента (оно должно соответствовать bacula-fd.conf, это не обязательно, но рекомендуется); в строке Адрес введите IP-адрес или FQDN вашего клиента; и, наконец, в поле Пароль вводите ранее скопированный во время установки пароль из bacula-fd.conf. Например:
• Сохраните и закройте файл bacula-dir.conf.
• Перезагрузите bacula-dir или запустите его снова в bconsole для того, чтобы принятые изменения вступили в силу.
• Через bconsole создайте статус клиента для вашей клиентской машины. Если ответом на команду будет корректное имя клиента, версия и список работ — ваша настройка завершилась успешно и Директор способен присоединиться к клиенту.

Теперь, когда клиент присоединен к Директору и протестирован, время создать новую Работу и новый FileSet. Начните с повторного запуска bacula-dir.conf:

• Добавьте новую функцию под названием Работа (подсказка: скопируйте существующую для облегчения процесса).
• Переименуйте Работу. Новое имя должно ссылаться на имя клиента, которое было ранее указано в клиенте как в ресурсе. Также в это же время вы можете назначить на эту Работу новый FileSet, который еще не существует, но который мы создадим с таким же именем, как указано ниже.
• Создайте новый FileSet с тем же именем, что и Работа (пример: FileSet = fileserver_set). Важно помнить, что для изменения параметров “включить” и “исключить” в плане папок вам понадобится бэкап нового клиента, а для этого в Windows вы можете использовать только обыкновенный символ / и ни в коем случае не \, а также что весь путь необходимо выделить кавычками. Например:
• Перезапустите bacula-dir или используйте команду reload в bconsole для того, чтобы сохранить и применить изменения.
• Протестируйте ваши новые настройки с помощью команды estimate quote в bconsole. Она должна показать файлы, которые Bacula должна забэкапить в начале Работы, а также их суммарный размер и число файлов, которые будут скопированы.
• Если хотите — запустите ваш первый бэкап. Не забудьте про процесс работы — чтение сообщений (команда message в bconsole), использование команд status director, client и storage (каждая из них должна давать различающиеся детали касательно запущенной Работы); а также список Работ, предоставляющий набор работ, которые выполняются или уже завершены.

The Windows Version of Bacula

At the current time only the File daemon or Client program has been thouroughly tested on Windows and is suitable for a production environment. As a consequence, when we speak of the Windows version of Bacula below, we are referring to the File daemon (client) only.

As of Bacula version 1.39.20 or greater, the installer is capable of installing not just the Client program, but also the Director and the Storage daemon and all the other programs that were previously available only on Unix systems. These additional programs, notably the Director and Storage daemon, have been partially tested, are reported to have some bugs, and still need to be documented. They are not yet supported, and we cannot currently accept or fix bug reports on them. Consequently, please test them carefully before putting them into a critical production environment.

The Windows version of the Bacula File daemon has been tested on Win98, WinMe, WinNT, WinXP, Win2000, and Windows 2003 systems. We have coded to support Win95, but no longer have a system for testing. The Windows version of Bacula is a native Win32 port, but there are very few source code changes to the Unix code, which means that the Windows version is for the most part running code that has long proved stable on Unix systems. When running, it is perfectly integrated with Windows and displays its icon in the system icon tray, and provides a system tray menu to obtain additional information on how Bacula is running (status and events dialog boxes). If so desired, it can also be stopped by using the system tray menu, though this should normally never be necessary.

Once installed Bacula normally runs as a system service. This means that it is immediately started by the operating system when the system is booted, and runs in the background even if there is no user logged into the system.

Win32 Installation

Normally, you will install the Windows version of Bacula from the binaries. This install is standard Windows .exe that runs an install wizard using the NSIS Free Software installer, so if you have already installed Windows software, it should be very familiar to you.

If you have a previous version Bacula (1.39.20 or lower) installed, you should stop the service, uninstall it, and remove the Bacula installation directory possibly saving your bacula-fd.conf, bconsole.conf, and bwx-console.conf files for use with the new version you will install. The Uninstall program is normally found in c:\bacula\Uninstall.exe . We also recommend that you completely remove the directory c:\bacula , because the current installer uses a different directory structure (see below).

Providing you do not already have Bacula installed, the new installer (1.39.22 and later) installs the binaries and dlls in c:\Program Files\Bacula\bin and the configuration files in c:\Documents and Settings\All Users\Application Data\Bacula In addition, the Start>All Programs>Bacula menu item will be created during the installation, and on that menu, you will find items for editing the configuration files, displaying the document, and starting bwx-console or bconsole.

Finally, proceed with the installation.

You must be logged in as Administrator to the local machine to do a correct installation, if not, please do so before continuing. Some users have attempted to install logged in as a domain administrator account and experienced permissions problems attempting to run Bacula, so we don’t recommend that option.

Simply double click on the winbacula-1.xx.0.exe NSIS install icon. The actual name of the icon will vary from one release version to another.

Once launched, the installer wizard will ask you if you want to install Bacula.

Next you will be asked to select the installation type.

If you proceed, you will be asked to select the components to be installed. You may install the Bacula program (Bacula File Service) and or the documentation. Both will be installed in sub-directories of the install location that you choose later. The components dialog looks like the following:

If you are installing for the first time, you will be asked to enter some very basic information about your configuration. If you are not sure what to enter, or have previously saved configuration files, you can put anything you want into the fields, then either replace the configuration files later with the ones saved, or edit the file.

If you are upgrading an existing installation, the following will not be displayed.

While the various files are being loaded, you will see the following dialog:

Finally, the finish dialog will appear:

That should complete the installation process. When the Bacula File Server is ready to serve files, an icon representing a cassette (or tape) will appear in the system tray ; right click on it and a menu will appear.

The Events item is currently unimplemented, by selecting the Status item, you can verify whether any jobs are running or not.

When the Bacula File Server begins saving files, the color of the holes in the cassette icon will change from white to green , and if there is an error, the holes in the cassette icon will change to red .

If you are using remote desktop connections between your Windows boxes, be warned that that tray icon does not always appear. It will always be visible when you log into the console, but the remote desktop may not display it.

After installing Bacula and before running it, you should check the contents of the configuration files to ensure that they correspond to your installation. You can get to them by using: the Start>All Programs>Bacula menu item.

Finally, but pulling up the Task Manager (ctl-alt-del), verify that Bacula is running as a process (not an Application) with User Name SYSTEM. If this is not the case, you probably have not installed Bacula while running as Administrator, and hence it will be unlikely that Bacula can access all the system files.

Once Bacula has been installed, it can be uninstalled using the standard Windows Add/Remove Programs dialog found on the Control panel.

Dealing with Win32 Problems

Sometimes Win32 machines the File daemon may have very slow backup transfer rates compared to other machines. To you might try setting the Maximum Network Buffer Size to 32,768 in both the File daemon and in the Storage daemon. The default size is larger, and apparently some Windows ethernet controllers do not deal with a larger network buffer size.

Many Windows ethernet drivers have a tendency to either run slowly due to old broken firmware, or because they are running in half-duplex mode. Please check with the ethernet card manufacturer for the latest firmware and use whatever techniques are necessary to ensure that the card is running in duplex.

If you are not using the portable option, and you have VSS (Volume Shadow Copy) enabled in the Director, and you experience problems with Bacula not being able to open files, it is most likely that you are running an antivirus program that blocks Bacula from doing certain operations. In this case, disable the antivirus program and try another backup. If it succeeds, either get a different (better) antivirus program or use something like RunClientJobBefore/After to turn off the antivirus program while the backup is running.

If turning off anti-virus software does not resolve your VSS problems, you might have to turn on VSS debugging. The following link describes how to do this: http://support.microsoft.com/kb/887013/en-us.

In Microsoft Windows Small Business Server 2003 the VSS Writer for Exchange is turned off by default. To turn it on, please see the following link: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q838183

The most likely source of problems is authentication when the Director attempts to connect to the File daemon that you installed. This can occur if the names and the passwords defined in the File daemon’s configuration file bacula-fd.conf file on the Windows machine do not match with the names and the passwords in the Director’s configuration file bacula-dir.conf located on your Unix/Linux server.

More specifically, the password found in the Client resource in the Director’s configuration file must be the same as the password in the Director resource of the File daemon’s configuration file. In addition, the name of the Director resource in the File daemon’s configuration file must be the same as the name in the Director resource of the Director’s configuration file.

It is a bit hard to explain in words, but if you understand that a Director normally has multiple Clients and a Client (or File daemon) may permit access by multiple Directors, you can see that the names and the passwords on both sides must match for proper authentication.

One user had serious problems with the configuration file until he realized that the Unix end of line conventions were used and Bacula wanted them in Windows format. This has not been confirmed though, and Bacula version 2.0.0 and above should now accept all end of line conventions (Win32, Unix, Mac).

Running Unix like programs on Windows machines is a bit frustrating because the Windows command line shell (DOS Window) is rather primitive. As a consequence, it is not generally possible to see the debug information and certain error messages that Bacula prints. With a bit of work, however, it is possible. When everything else fails and you want to see what is going on, try the following:

The precise path to bacula-fd depends on where it is installed. The example above is the default used in 1.39.22 and later. The -t option will cause Bacula to read the configuration file, print any error messages and then exit. the > redirects the output to the file named out , which you can list with the type command.

If something is going wrong later, or you want to run Bacula with a debug option, you might try starting it as:

In this case, Bacula will run until you explicitly stop it, which will give you a chance to connect to it from your Unix/Linux server. In later versions of Bacula (1.34 on, I think), when you start the File daemon in debug mode it can write the output to a trace file bacula.trace in the current directory. To enable this, before running a job, use the console, and enter:

then run the job, and once you have terminated the File daemon, you will find the debug output in the bacula.trace file, which will probably be located in the same directory as bacula-fd.exe.

In addition, you should look in the System Applications log on the Control Panel to find any Windows errors that Bacula got during the startup process.

Finally, due to the above problems, when you turn on debugging, and specify trace=1 on a setdebug command in the Console, Bacula will write the debug information to the file bacula.trace in the directory from which Bacula is executing.

If you are having problems with ClientRunBeforeJob scripts randomly dying, it is possible that you have run into an Oracle bug. See bug number 622 in the bugs.bacula.org database. The following information has been provided by a user on this issue:

You may wish to start the daemon with debug mode on rather than doing it using bconsole. To do so, edit the following registry key:

using regedit, then add -dnn after the /service option, where nn represents the debug level you want.

If you are not using the VSS (Volume Shadow Copy) option described in the next section of this chapter, and if any applications are running during the backup and they have files opened exclusively, Bacula will not be able to backup those files, so be sure you close your applications (or tell your users to close their applications) before the backup. Fortunately, most Microsoft applications do not open files exclusively so that they can be backed up. However, you will need to experiment. In any case, if Bacula cannot open the file, it will print an error message, so you will always know which files were not backed up. For version 1.37.25 and greater, see the section below on Volume Shadow Copy Service that permits backing up any file.

During backup, Bacula doesn’t know about the system registry, so you will either need to write it out to an ASCII file using regedit /e or use a program specifically designed to make a copy or backup the registry.

In Bacula version 1.31 and later, we use Windows backup API calls by default. Typical of Windows, programming these special BackupRead and BackupWrite calls is a real nightmare of complications. The end result gives some distinct advantages and some disadvantages.

First, the advantages are that on WinNT/2K/XP systems, the security and ownership information is now backed up. In addition, with the exception of files in exclusive use by another program, Bacula can now access all system files. This means that when you restore files, the security and ownership information will be restored on WinNT/2K/XP along with the data.

The disadvantage of the Windows backup API calls is that it produces non-portable backups. That is files and their data that are backed up on WinNT using the native API calls (BackupRead/BackupWrite) cannot be restored on Win95/98/Me or Unix systems. In principle, a file backed up on WinNT can be restored on WinXP, but this remains to be seen in practice (not yet tested). In addition, the stand-alone tools such as bls and bextract cannot be used to retrieve the data for those files because those tools are not available on Windows. All restores must use the Bacula restore command. As of Bacula 1.39.x, thanks to Thorsten Engel, this restriction is removed, and Bacula should be able to read non-portable backups on any system and restore the data appropriately. However, on a system that does not have the BackupRead/BackupWrite calls (older Windows versions and all Unix/Linux machines), though the file data can be restored, the Windows security and access control data will not be restored. This means that a standard set of access permissions will be set for such restored files.

As a default, Bacula backs up Windows systems using the Windows API calls. If you want to backup data on a WinNT/2K/XP system and restore it on a Unix/Win95/98/Me system, we have provided a special portable option that backs up the data in a portable fashion by using portable API calls. See the portable option on the Include statement in a FileSet resource in the Director’s configuration chapter for the details on setting this option. However, using the portable option means you may have permissions problems accessing files, and none of the security and ownership information will be backed up or restored. The file data can, however, be restored on any system.

You should always be able to restore any file backed up on Unix or Win95/98/Me to any other system. On some systems, such as WinNT/2K/XP, you may have to reset the ownership of such restored files. Any file backed up on WinNT/2K/XP should in principle be able to be restored to a similar system (i.e. WinNT/2K/XP), however, I am unsure of the consequences if the owner information and accounts are not identical on both systems. Bacula will not let you restore files backed up on WinNT/2K/XP to any other system (i.e. Unix Win95/98/Me) if you have used the defaults.

Finally, if you specify the portable=yes option on the files you back up. Bacula will be able to restore them on any other system. However, any WinNT/2K/XP specific security and ownership information will be lost.

The following matrix will give you an idea of what you can expect. Thanks to Marc Brueckner for doing the tests:

Backup OS	Restore OS	Results
WinMe	WinMe	Works
WinMe	WinNT	Works (SYSTEM permissions)
WinMe	WinXP	Works (SYSTEM permissions)
WinMe	Linux	Works (SYSTEM permissions)
WinXP	WinXP	Works
WinXP	WinNT	Works (all files OK, but got «The data is invalid» message)
WinXP	WinMe	Error: Win32 data stream not supported.
WinXP	WinMe	Works if Portable=yes specified during backup.
WinXP	Linux	Error: Win32 data stream not supported.
WinXP	Linux	Works if Portable=yes specified during backup.
WinNT	WinNT	Works
WinNT	WinXP	Works
WinNT	WinMe	Error: Win32 data stream not supported.
WinNT	WinMe	Works if Portable=yes specified during backup.
WinNT	Linux	Error: Win32 data stream not supported.
WinNT	Linux	Works if Portable=yes specified during backup.
Linux	Linux	Works
Linux	WinNT	Works (SYSTEM permissions)
Linux	WinMe	Works
Linux	WinXP	Works (SYSTEM permissions)

Note: with Bacula versions 1.39.x and later, non-portable Windows data can be restore to any machine.

Microsoft added VSS to Windows XP and Windows 2003. From the perspective of a backup-solution for Windows, this is an extremely important step. VSS allows Bacula to backup open files and even to interact with applications like RDBMS to produce consistent file copies. VSS aware applications are called VSS Writers, they register with the OS so that when Bacula wants to do a Snapshot, the OS will notify the register Writer programs, which may then create a consistent state in their application, which will be backed up. Examples for these writers are «MSDE» (Microsoft database engine), «Event Log Writer», «Registry Writer» plus 3rd party-writers. If you have a non-vss aware application (e.g. SQL Anywhere or probably MySQL), a shadow copy is still generated and the open files can be backed up, but there is no guarantee that the file is consistent.

Bacula produces a message from each of the registered writer programs when it is doing a VSS backup so you know which ones are correctly backed up.

Bacula supports VSS on both Windows 2003 and Windows XP. Technically Bacula creates a shadow copy as soon as the backup process starts. It does then backup all files from the shadow copy and destroys the shadow copy after the backup process. Please have in mind, that VSS creates a snapshot and thus backs up the system at the state it had when starting the backup. It will disregard file changes which occur during the backup process.

VSS can be turned on by placing an

in your FileSet resource.

The VSS aware File daemon has the letters VSS on the signon line that it produces when contacted by the console. For example: the VSS is shown in the line above. This only means that the File daemon is capable of doing VSS not that VSS is turned on for a particular backup. There are two ways of telling if VSS is actually turned on during a backup. The first is to look at the status output for a job, e.g.: Here, you see under Running Jobs that JobId 1 is «VSS Backup Job started . » This means that VSS is enabled for that job. If VSS is not enabled, it will simply show «Backup Job started . » without the letters VSS.

The second way to know that the job was backed up with VSS is to look at the Job Report, which will look something like the following: In the above Job Report listing, you see that the VSS snapshot was generated for drive C (if other drives are backed up, they will be listed on the Drive(s)=»C» You also see the reports from each of the writer program. Here they all report VSS_WS_STABLE, which means that you will get a consistent snapshot of the data handled by that writer.

If you are experiencing problems such as VSS hanging on MSDE, first try running vssadmin to check for problems, then try running ntbackup which also uses VSS to see if it has similar problems. If so, you know that the problem is in your Windows machine and not with Bacula.

The FD hang problems were reported with MSDEwriter when:

• a local firewall locked local access to the MSDE TCP port (MSDEwriter seems to use TCP/IP and not Named Pipes).
• msdtcs was installed to run under «localsystem»: try running msdtcs under networking account (instead of local system) (com+ seems to work better with this configuration).

If you turn on the firewalling feature on Windows (default in WinXP SP2), you are likely to find that the Bacula ports are blocked and you cannot communicate to the other daemons. This can be deactivated through the Security Notification dialog, which is apparently somewhere in the Security Center . I don’t have this on my computer, so I cannot give the exact details.

is purported to disable the firewall, but this command is not accepted on my WinXP Home machine.

If you want to see if the File daemon has properly opened the port and is listening, you can enter the following command in a shell window:

TopView is another program that has been recommend, but it is not a standard Win32 program, so you must find and download it from the Internet.

We don’t currently have a good solution for disaster recovery on Windows as we do on Linux. The main piece lacking is a Windows boot floppy or a Windows boot CD. Microsoft releases a Windows Pre-installation Environment ( WinPE ) that could possibly work, but we have not investigated it. This means that until someone figures out the correct procedure, you must restore the OS from the installation disks, then you can load a Bacula client and restore files. Please don’t count on using bextract to extract files from your backup tapes during a disaster recovery unless you have backed up those files using the portable option. bextract does not run on Windows, and the normal way Bacula saves files using the Windows API prevents the files from being restored on a Unix machine. Once you have an operational Windows OS loaded, you can run the File daemon and restore your user files.

Please see Disaster Recovery of Win32 Systems for the latest suggestion, which looks very promising.

It looks like Bart PE Builder, which creates a Windows PE (Pre-installation Environment) Boot-CD, may be just what is needed to build a complete disaster recovery system for Win32. This distribution can be found at http://www.nu2.nu/pebuilder/.

sectionWindows Backup Problems If during a Backup, you get the message: ERR=Access is denied and you are using the portable option, you should try both adding both the non-portable (backup API) and the Volume Shadow Copy options to your Director’s conf file.

In the Options resource:

In the FileSet resource:

In general, specifying these two options should allow you to backup any file on a Windows system. However, in some cases, if users have allowed to have full control of their folders, even system programs such a Bacula can be locked out. In this case, you must identify which folders or files are creating the problem and do the following:

1. Grant ownership of the file/folder to the Administrators group, with the option to replace the owner on all child objects.
2. Grant full control permissions to the Administrators group, and change the user’s group to only have Modify permission to the file/folder and all child objects.

Thanks to Georger Araujo for the above information.

If you restore files backed up from WinNT/XP/2K to an alternate directory, Bacula may need to create some higher level directories that were not saved (or restored). In this case, the File daemon will create them under the SYSTEM account because that is the account that Bacula runs under as a service. As of version 1.32f-3, Bacula creates these files with full access permission. However, there may be cases where you have problems accessing those files even if you run as administrator. In principle, Microsoft supplies you with the way to cease the ownership of those files and thus change the permissions. However, a much better solution to working with and changing Win32 permissions is the program SetACL , which can be found at http://setacl.sourceforge.net/.

If you have not installed Bacula while running as Administrator and if Bacula is not running as a Process with the userid (User Name) SYSTEM, then it is very unlikely that it will have sufficient permission to access all your files.

Some users have experienced problems restoring files that participate in the Active Directory. They also report that changing the userid under which Bacula (bacula-fd.exe) runs, from SYSTEM to a Domain Admin userid, resolves the problem.

The following solution was provided by Dan Langille . The steps are performed using Windows 2000 Server but they should apply to most Win32 platforms. The procedure outlines how to deal with a problem which arises when a restore creates a top-level new directory. In this example, «top-level» means something like c:\src , not c:\tmp\src where c:\tmp already exists. If a restore job specifies / as the Where: value, this problem will arise.

The problem appears as a directory which cannot be browsed with Windows Explorer. The symptoms include the following message when you try to click on that directory:

If you encounter this message, the following steps will change the permissions to allow full access.

1. right click on the top level directory (in this example, c:/src ) and select Properties .
2. click on the Security tab.
3. If the following message appears, you can ignore it, and click on OK .

You should see something like this:

click on Advanced

click on the Owner tab

Change the owner to something other than the current owner (which is SYSTEM in this example as shown below).

ensure the «Replace owner on subcontainers and objects» box is checked

click on OK

When the message «You do not have permission to read the contents of directory c:\src\basis. Do you wish to replace the directory permissions with permissions granting you Full Control?», click on Yes.

Click on OK to close the Properties tab

With the above procedure, you should now have full control over your restored directory.

In addition to the above methods of changing permissions, there is a Microsoft program named cacls that can perform similar functions.

A suggestion by Damian Coutts using Microsoft’s NTBackup utility in conjunction with Bacula should permit a full restore of any damaged system files on Win2K/XP. His suggestion is to do an NTBackup of the critical system state prior to running a Bacula backup with the following command:

The backup is the command, the systemstate says to backup only the system state and not all the user files, and the /F c:\systemstate.bkf specifies where to write the state file. this file must then be saved and restored by Bacula.

To restore the system state, you first reload a base operating system if the OS is damaged, otherwise, this is not necessary, then you would use Bacula to restore all the damaged or lost user’s files and to recover the c:\systemstate.bkf file. Finally if there are any damaged or missing system files or registry problems, you run NTBackup and catalogue the system statefile, and then select it for restore. The documentation says you can’t run a command line restore of the systemstate.

To the best of my knowledge, this has not yet been tested. If you test it, please report your results to the Bacula email list.

Please see the Director’s Configuration chapter of this manual for important considerations on how to specify Windows paths in Bacula FileSet Include and Exclude directives.

Bacula versions prior to 1.37.28 do not support Windows Unicode filenames. As of that version, both bconsole and bwx-console support Windows Unicode filenames. There may still be some problems with multiple byte characters (e.g. Chinese, . ) where it is a two byte character but the displayed character is not two characters wide.

Path/filenames longer than 260 characters (up to 32,000) are supported beginning with Bacula version 1.39.20. Older Bacula versions support only 260 character path/filenames.

These options are not normally seen or used by the user, and are documented here only for information purposes. At the current time, to change the default options, you must either manually run Bacula or you must manually edit the system registry and modify the appropriate entries.

In order to avoid option clashes between the options necessary for Bacula to run on Windows and the standard Bacula options, all Windows specific options are signaled with a forward slash character (/), while as usual, the standard Bacula options are signaled with a minus (-), or a minus minus ( — ). All the standard Bacula options can be used on the Windows version. In addition, the following Windows only options are implemented:

/service Start Bacula as a service

/run Run the Bacula application

/install Install Bacula as a service in the system registry

/remove Uninstall Bacula from the system registry

/about Show the Bacula about dialogue box

/status Show the Bacula status dialogue box

/events Show the Bacula events dialogue box (not yet implemented)

/kill Stop any running Bacula

/help Show the Bacula help dialogue box

It is important to note that under normal circumstances the user should never need to use these options as they are normally handled by the system automatically once Bacula is installed. However, you may note these options in some of the .bat files that have been created for your use.

Some users like to shutdown their Windows machines after a backup using a Client Run After Job directive. If you want to do something similar, you might take the shutdown program from the apcupsd project or one from the Sysinternals project.