From the current bacula console manual:
If you do a status dir, it will by default list the first occurrence
of all jobs that are scheduled today and tomorrow. If you wish to see
the jobs that are scheduled in the next three days (e.g. on Friday you
want to see the first occurrence of what tapes are scheduled to be
used on Friday, the weekend, and ...
You don't need to restart Bacula for every change. Just run a reload from the bconsole and it will reread the configuration. Of course you can make your config very dynamic. Bacula can look in directories for config files and merge them all together. We have different config files for each job. You can create a tool the make these config files. So it is ...
You are trying to use the director to test the storage daemon's config. This probably won't work, as an SD's config is not generally a valid director config. Try using the storage daemon to test its own config:
sudo bacula-sd -tc /etc/bacula-sd.conf
AFAIK copying jobs between storage-daemons is still not possible.
Yes, at this time. Both migration and copy jobs are restricted at this
time to using a single SD for source and destination, because there is
no currently existing protocol in Bacula for one SD to communicate
directly with another.
(see 2nd answer here: http://bacula.10910.n7....
In the tape world this is often done so you can easily grab your full backups and ship them off-site/archive them/etc.
If you are backing up to disk this is probably less of an issue for you, unless you are using a removable disk and want to be able to take the entire "full backups" drive off-site.
Re: pool selection, I believe Bacula uses the running job ...
In order to get Bacula to do what you want you need more than just volumes - you need to put those volumes into separate pools and let your jobs know that you want to use different pools for different backup levels.
The magic syntax is:
Name = "Test"
Type = Backup
Client = backup-fd
FileSet = "FileSetTest"
The problem is partly within the configuration files and partly elsewhere. On some of the 20 machines where Bacula was installed I have altered the default port on which bacula-fd is listening (had reasons for that) and this proved to be the root of the problem. As for the /etc/bacula/bacula-fd.conf the relevant line is this one: FDport = 13802.
The thing ...
I found (a) the solution...
it seems that the key is here:
It occurs automatically, if the source SD and destination SD of a Copy or Migration job are different.
My goal was to copy some backup jobs from Asia to Europe. In order to do this I have created a Device in the Europe SD:
Name = asiaBackup
Media Type = File1
Device Type = ...
You have multiple options to recover from this, but it should always be possible to rebuild the database of the backup content with the bscan program.
Depending on how your system is configured and what was damaged on the crashed bacula server, you might also have a bootstrap file helping you out.
Refer to the Bacula documentation for more help.
It looks like the issue was a blank line in my bacula_backup_file_list file. With a trailing blank line, bacula starts backing up the root of the drive as well as everything that I've specifically included; without it, it only backs up what I've listed.
Bacula is backing up exactly what you're telling it to. You have listed all of the directories that you want to exclude (based on your comments) in your include section (based on the configuration you posted above).
Put the list of wildcard directories to be excluded in the correct place and Bacula will do what you want.
(Yes the Bacula manual isn't the ...
Make all the jobs but one have the same priority, the same start time, and set concurrency to 1, and disallow mixed priorities. Then for the last job, set a lower priority, and schedule it so it starts a minute (or few) later than your other jobs. Put the Run After only on that last job.
For example, let's say you have job1, job2, job3, job4 and job5. job1-...
After a few days with the solution, it seems to be working, so here it goes:
Up to the example, lets say we have the following jobs:
Then assuming the --job as a convention, the file set should look like:
Name = "someapp-fileset"
signature = MD5
Taking the individual points of your question:
Requirement 1 - Load Spreading
You need to figure this one out for your environment -- "reasonable" depends on a lot of factors (how many machines, how much data, what kind of media you're backing up to, how much bandwidth you have available, how much money your boss is willing to allocate for backups, whether ...
The error message says:
Passwords or names not the same or
Maximum Concurrent Jobs exceeded on the FD or
FD networking messed up (restart daemon).
The configuration on your director:
# Client information for my-client-hostname
Name = my-client-hostname
Password = "my_secret_password"
Address = my-client-hostname....
Bacula doesn't support "volume space reclamation" as you describe, but it does support "Virtual Backups" (what other systems call "Synthetic Backup" which seems to do what you're looking for.
Your backup media is still subject to whatever retention periods you've configured, but you could set those to an appropriate period to avoid having extra full backups ...
You have to add mysqldump or a script which dumps your database before the job run:
RunsWhen = Before
FailJobOnError = Yes
Command = "mysqldump ..."
If you need to run script in remote webserver, add the RunsOnClient option in RunScript.
RunsWhen = Before
FailJobOnError = Yes
RunsOnClient = Yes
Command = "...
It was SQL.
By default, each time bacula-fd sends a new file, bacula-sd tries to (via bacula-dir) insert file attributes into SQL batch table. If you have a lots of small files, and your SQL is not blazingly fast, it will insert small delay. Many small delays = throttled speed = canceled backups due to Max Run Sched Time exceeded. And due to architecture ...
It's always possible to do a partial restore of a backup. I'm not familiar with Bacula but I will outline the general methods:
Most backup software actually allows you to do a partial restore of a full backup, by design. If you run the restore command for Bacula then I'm sure it will allow you to select a list of files or directory trees to restore. "Halp, ...
Just to add one thing. Try to use bscan and you can "read" the Volumes again ( the copied ones) and import them into the Catalog of the other location. Than you can restore them in the second site also ;) thus avoiding the dependency on the first director, in case anything goes wrong.
Hope it helps.
It's hard to know the exact problem without seeing your configuration, since there are so many parameters available to set. However, I suspect your immediate problem is simply that Bacula won't reuse the space until it must, even if the retention periods expire. The trick is to inform it how to know when it "must".
Remember, disk storage is implemented ...
The bextract manual (at least for ver. 5.2, the most popular in distros) does not list any option to specify remote host. So your options are:
mount a share from the remote machine in the director's OS;
create a temporary, empty catalog database and use bscan to recover all metadata and proceed with normal recovery.
From Bacula manual:
The bscan program ...
Well, depends on you backup/restore strategy. We have 16 active virtual machines. The initial steps on our backup strategy are:
shutdown the virtual machine (ACPI)
backup the directory containing the virtual machine
restart the virtual machine
the steps 1 & 3 assures the health of the always unstable Windows servers.
On our case, the virtual machines ...