You can "copy" jobs based on various criterias. You can copy all jobs that were backed up into one specific volume, all jobs from a client, etc. There are a few options for that. Basically, you will create a copy job that will copy your backups based on specifically conditions from one pool (where you normally have your backups) to another pool (the next pool defined in the original pool resource used for your original backups).

An interesting directive for the migration/copy pool is:

PoolUncopiedJobs This selection which copies all jobs from a pool to an other pool which were not copied before is available only for copy Jobs.

So, sure you can copy "a volume" (all the jobs that were copied in an original volume) using copy jobs.

You´re welcome!

Best regards,

Ana

On Mon, May 18, 2015 at 2:07 PM, Carlo Filippetto <carlo.filippetto AT gmail DOT com> wrote:

Thank to you!

I have another question: with the 'copy' job, SD to SD, I can copy a Volume or I have to copy every single job?

Thank you

2015-05-18 19:04 GMT+02:00 Ana Emília M. Arruda <emiliaarruda AT gmail DOT com>:

Hello Carlo,

Don´t worry!

About to copying only the confs and db, I was supposing that on site2 there would be an identical installation as it is on site1. Since clustering is not a builtin Bacula functionality (I´m affraid there is one that I´m not aware), I didn´t realize that it could be done between the two linux hosts. Without the bacula-dir clustering solution, it would be a manual process start bacula-dir on site2 when site1 becomes unavailable.

Thank you!

Best regards,

Ana

​

I'll put the two director in cluster, mysql in replication, and conf in sync.

If you move only the conf and the db you can't do backup from site2, because the machine check the IP address, with cluster I want to sckip this problem.

On Mon, May 18, 2015 at 12:13 PM, Carlo Filippetto <carlo.filippetto AT gmail DOT com> wrote:

Sorry for the delay!

On Fri, May 15, 2015 at 11:23 AM, Carlo Filippetto <carlo.filippetto AT gmail DOT com> wrote:

Thank you.

I will use the sd2sd solution.

2015-05-15 15:54 GMT+02:00 Davide Giunchi <davide.giunchi AT soasi DOT com>:

problem: you need a lot of bandiwidth ( = € )! then you must keep always sync the servers, periodically check that everithing is working good, and then periodically to dr tests.
benefit: fast dr

I read about Virtual Full, I can use it to create a full on remote site instead off move the whole VM?

​Are you talking about Virtual Backup (Vbackup)? It is intended to "consolidate" a full backup, the most recent differential and the following incremental into one new full backup. This new full backup can be placed in your site2.

Fantasctic, I read in the new features that I can consolidate not only the last, but the backup that I want.

 

I´m not sure if this is what you´re wondering. If you want to keep site2 with the same volume data as site1, you will need daily copy jobs for this or some other kind of data replication.

Yes, I want to have the same data on site1 and site2, but I can't migrate 500Gb of Backup every night

So I will do a first full migration, and after I'll go on only with the daily and I will use the consololitate backup (Vbackup) to have a full.

 

The director master stay on site 1, the site 2 is offline since the firts goes down.

The master on site 1 know the volumes on site 2 with SD to SD copy? (I think yes, it is an SD that he manage)

​Yes, if you use copy or migrate jobs. Are you also going to copy your volumes data from site1 to site2?​

I´m not sure about your needs, but if you´re going to replicate your volumes data from site1 to site2, I would prefer to replicate bacula´s configuration files and a catalog backup from site1 to site2. And when you need to use bacula on site2, you could just start it.

​​

I'll put the two director in cluster, mysql in replication, and conf in sync.

If you move only the conf and the db you can't do backup from site2, because the machine check the IP address, with cluster I want to sckip this problem.

Thank you