Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

On Wednesday 2019-04-24 22:39:01 Heitor Faria wrote:
> Hello Radoslaw,
> 
> > You cannot run two always on replicated directors. Why? Every single
> > Bacula Director requires a separate copy of the catalog database. So,
> > two always on directors require two separate databases, so you cannot
> > setup online replication in this setup. It just won't work.
> 
> This is not very accurate.

Not accurate but the conclusion is correct.

> I was able to run several concurrent jobs using to Directors with the
> same name, same Catalog and same clients: [
> https://pasteboard.co/IbHjY0J.png | https://pasteboard.co/IbHjY0J.png ]
> I just used different Pools and Storage. The plugin jobs failed for

And different job configurations.

> obvious reason. The failed plugin Jobs and Load Balancing might be
> solved using the Maximum Director Concurrent Jobs and not allowing
> duplicated jobs. The Storage and Pools SPOF can be resolved using
> Bacula Enterprise Shared SAN plugin or a NFS share for both SDs (disk
> only). The Catalog SPOF Pgsql might be solved with Master - Master
> replication. Configuration replication with rsync or any trivial
> mechanism, that is very easy to manage. For bconsole and Web GUI, you
> can even use a DNS failover as the cherry on the top. I will keep
> testing.

I very much dislike the use of rsync tool in HA projects.

We should start thinking out of the usual sysadmin perspective and
try to realize what change in the bacula as a system would be needed
to make the things discussed in this thread possible rather than
proving that we can make fragile and hard to maintain proof of concept.



Regards!

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Hello Radoslaw, 

> You cannot run two always on replicated directors. Why? Every single Bacula
> Director requires a separate copy of the catalog database. So, two always on
> directors require two separate databases, so you cannot setup online
> replication in this setup. It just won't work.

This is not very accurate. 
I was able to run several concurrent jobs using to Directors with the same 
name, same Catalog and same clients: [ https://pasteboard.co/IbHjY0J.png | 
https://pasteboard.co/IbHjY0J.png ] 
I just used different Pools and Storage. The plugin jobs failed for obvious 
reason. 
The failed plugin Jobs and Load Balancing might be solved using the Maximum 
Director Concurrent Jobs and not allowing duplicated jobs. 
The Storage and Pools SPOF can be resolved using Bacula Enterprise Shared SAN 
plugin or a NFS share for both SDs (disk only). 
The Catalog SPOF Pgsql might be solved with Master - Master replication. 
Configuration replication with rsync or any trivial mechanism, that is very 
easy to manage. 
For bconsole and Web GUI, you can even use a DNS failover as the cherry on the 
top. 
I will keep testing. 

Regards, 
-- 

MSc Heitor Faria 
CEO Bacula LATAM 
mobile1: + 1 909 655-8971 
mobile2: + 55 61 98268-4220 
[ https://www.linkedin.com/in/msc-heitor-faria-5ba51b3 ] 
[ http://www.bacula.com.br/ ] 

América Latina 
[ http://bacula.lat/ | bacula.lat ] | [ http://www.bacula.com.br/ | 
bacula.com.br ] 
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Dimitri Maziuk via Bacula-users]

On 4/24/19 11:44 AM, Radosław Korzeniewski wrote:

> To make a reschedule after restart possible a Director should save
> reschedule state in catalog database. It should save the number of
> reschedules passed and an exact time when last reschedule pass started to
> checks if it is required to continue any rescheduled jobs.

If you have a multi-terabyte job that takes 20 hours to complete, and
the backup schedule is every 24 hours, you're better off just leaving it
be until the next scheduled backup.

I.e. IMO auto-rescheduling failed jobs has bigger problems than
persisting the state across director restarts.
-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Radosław Korzeniewski]

Hello,

I promised to not make any followup to this thread, but below question
requires an answer!

wt., 23 kwi 2019 o 16:40 Josh Fisher  napisał(a):

> but the automated "Reschedule On Error" feature
>> allows restarting them after the fail-over.
>
>
> Well, no. Rescheduling is based on actual job thread running on Bacula
> Director. Any Director restart will stop this feature for a particular
> jobid!
>
>
> Hmm. Then what is the status of a running job that is interrupted by a
> Director restart?
>
When Director starts it checks a catalog database to find any job with
Running status. If it finds some it changes its status to Failed.

> It is a running job when the Dir is stopped, and is an error job once
> restarted. How does that happen? If the job status is updated during
> Director startup, then why doesn't the reschedule occur?
>
Reschedule occur in the job thread loop. To make a reschedule working
Director manages some internal variables such as: int32_t reschedule_count;
/* Number of times rescheduled */ and reschedule interval as a simple sleep
in loop. The reschedule state is not saved, so during Director restart it
is impossible to recover this state.

To make a reschedule after restart possible a Director should save
reschedule state in catalog database. It should save the number of
reschedules passed and an exact time when last reschedule pass started to
checks if it is required to continue any rescheduled jobs. It is not
implemented now, IMHO.
As always YMMV.

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Radosław Korzeniewski]

Hello Heitor,

wt., 23 kwi 2019 o 13:50 Heitor Faria  napisał(a):

> Hello Radoslaw,
>
> I meditated a lot about this topic, and just to keep it short I will
> resume my conclusions:
>

The main conclusion I wrote in my previous email is a different dictionary
we use to describe the same things. Unless we move it to the same level,
our dispute is pointless.

But, we can go ahead so I'll practice my english. :)


>
> 1. HA means single points of failure elimination, reliable crossover and
> failure detection.
>

No, High Availability is a solution which allows for service to function
with as highest uptime as possible. It should be achieved using SPOF
elimination including a single server. I do not understand what a "reliable
crossover" is?


> I don't see how having two replicated always on Directors (perhaps with
> the same Director Name);
>

You cannot run two always on replicated directors. Why? Every single Bacula
Director requires a separate copy of the catalog database. So, two always
on directors require two separate databases, so you cannot setup online
replication in this setup. It just won't work.


> replicated job and client configurations;
>

Yes, you can achieve this with simple rsync or build in database
replication mechanism when using IBAdmin. :)


> replicated backup data
>

Bacula volumes? So you can achieve this with Bacula Copy Jobs. DRBD does
not work for tapes, sorry.


> and metadata;
>

I assume as a metadata you are referring to catalog database, so for
PostgreSQL you can use a streaming replication and master/standby mode of
operation as described in manual:
https://www.postgresql.org/docs/9.1/high-availability.html
But, the standby instance cannot be used for standard processing queries.
The HotStandby - a read only version is available. So you can perform
catalog database (metadata) replication, but you cannot use it for two
always on Directors.


> secondary Director de/activation mechanisms;
>

??? I do not understand, why do you need to deactivate secondary Director
while it is in always on mode? So is always on mode for secondary Director
really necessary?


> redundant storage possibility; cannot be considered a High Availability
> Solution.
>

Simple failover procedure for replicated database and Bacula Director above
require:
- stop a replication for database
- stop a configuration replication if implemented
- deactivate a main Director
- de/activate secondary Director
- promote secondary database as a master database
- run a secondary Director and promote it as a master
- delete all volumes from main storage to promote all replicated copy jobs
as main jobs
- implement a reverse database replication which requires to delete an old
database and make an initial data replication
- implement a reverse configuration replication
- implement a reverse copy jobs, make an initial volumes replication
- until ready (hours? days? weeks?) you cannot make a failback

To make a Director failover, you should (it is not strictly required)
failover its IP address. To make a SD failover you have to failover its IP
address to. You can assign a new IP addresses for both Director and SD but
it require to alter configuration before failover.

I will undergo a laboratory on that.
>

As I implement a lot of HA clustering solutions for backup and other
systems I'm extremely curious how your solution will work.

3. Every big data center application usually has their native cluster
> mechanism, so DRBD+whatever cannot be the considered the silver bullet. In
> fact, IMHO, it is a overkill to use your proposal to replicate the Director
> service,
>

I NEVER! proposed to replicate a Director service with HA! Please do not
impose it.


> and adds a lot of complexity.
>

I think we should stop our conversation here because it points to nowhere.
I think we are talking about the same things using different dictionaries,
words sentences, statements, so we do not understand each other.
I won't make any followup to this thread. And as always, it was a great
pleasure to be able to perform a such interesting conversation.

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[shouldbe q931]

On Tue, Apr 23, 2019 at 3:57 PM Josh Fisher  wrote:

>
> On 4/23/2019 9:43 AM, Gary R. Schmidt wrote:
> > On 23/04/2019 21:50, Heitor Faria wrote:
> >> Hello Radoslaw,
> >>
> >> I meditated a lot about this topic, and just to keep it short I will
> >> resume my conclusions:
> >>
> >> 1. HA means single points of failure elimination, reliable crossover
> >> and failure detection. I don't see how having two replicated always
> >> on Directors (perhaps with the same Director Name); replicated job
> >> and client configurations; replicated backup data and metadata;
> >> secondary Director de/activation mechanisms; redundant storage
> >> possibility; cannot be considered a High Availability Solution. I
> >> will undergo a laboratory on that.
> >
> > It is not HA because the jobs that have been running on the failed
> > server cannot be continued.
>
>
> Granted, but it is not a black and white distinction when there are
> multiple jobs scheduled for different times. At failover, currently
> running jobs fail, but future scheduled jobs will run on the other
> cluster node. Without any HA at all, none of the jobs would run. So in
> that respect, it is HA, it just isn't 100% HA.
>
>
There are many levels of hell high availability

The distinctions between DR (Disaster Recovery), BC (Business Continuity),
and HA (High Availability) have room for nuance.

As an example,is having multiple MX records (pointing at different hosts)
for email DR, BC or HA ?

I think the issue that makes people think of multiple MX records as HA, but
a similar situation with Bacula being DR, is the size (time) of the job,
and that email will be automatically (after a short delay) retried.

I'll get back under my rock now.

Cheers

Arne
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josh Fisher]

On 4/23/2019 9:43 AM, Gary R. Schmidt wrote:

On 23/04/2019 21:50, Heitor Faria wrote:

Hello Radoslaw,

I meditated a lot about this topic, and just to keep it short I will 
resume my conclusions:


1. HA means single points of failure elimination, reliable crossover 
and failure detection. I don't see how having two replicated always 
on Directors (perhaps with the same Director Name); replicated job 
and client configurations; replicated backup data and metadata; 
secondary Director de/activation mechanisms; redundant storage 
possibility; cannot be considered a High Availability Solution. I 
will undergo a laboratory on that.


It is not HA because the jobs that have been running on the failed 
server cannot be continued.



Granted, but it is not a black and white distinction when there are 
multiple jobs scheduled for different times. At failover, currently 
running jobs fail, but future scheduled jobs will run on the other 
cluster node. Without any HA at all, none of the jobs would run. So in 
that respect, it is HA, it just isn't 100% HA.





___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josh Fisher]

On 4/19/2019 4:46 AM, Radosław Korzeniewski wrote:

Hello,

wt., 16 kwi 2019 o 17:29 Josh Fisher > napisał(a):



On 4/16/2019 10:45 AM, Dmitri Maziuk via Bacula-users wrote:
> On Mon, 15 Apr 2019 23:24:10 -0300
> Marcio Demetrio Bacci mailto:marcioba...@gmail.com>> wrote:
>
>> 5. Currently the OS and Backup disks are on the same DRBD
volume, so
>> would it be better to put the OS disk out of the DRBD volume?
(the VM
>> has frequently crashing what makes me think that excessive
writing on
>> the disk may be impacting the OS)
> I would put everything out of drbd volume because quite frankly
I don't
> see the point. I don't think you can fail over in a middle of a
backup,
> and without that, why not just put OS on NFS? -- or ZFS and send
> incremental snapshot as part of your manual failover. Using drbd for
> backup storage is just a waste of disk.


Running jobs will fail,


Assuming jobs fail because we failover the Bacula Director service, right?



Yes, but also if we failover the Storage Daemon.



but the automated "Reschedule On Error" feature
allows restarting them after the fail-over.


Well, no. Rescheduling is based on actual job thread running on Bacula 
Director. Any Director restart will stop this feature for a particular 
jobid!



Hmm. Then what is the status of a running job that is interrupted by a 
Director restart? It is a running job when the Dir is stopped, and is an 
error job once restarted. How does that happen? If the job status is 
updated during Director startup, then why doesn't the reschedule occur?





best regards
--
Radosław Korzeniewski
rados...@korzeniewski.net 


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Dmitri Maziuk via Bacula-users]

On Tue, 23 Apr 2019 23:43:12 +1000
"Gary R. Schmidt"  wrote:

> 1 - That was proper clusters, that was, not the half-arsed crap that 
> lusers call clustering these days.

It's called availability to the max. As in 737 Max.

-- 
Dmitri Maziuk 


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Hello Gary,

>> 1. HA means single points of failure elimination, reliable crossover and
>> failure detection. I don't see how having two replicated always on
>> Directors (perhaps with the same Director Name); replicated job and
>> client configurations; replicated backup data and metadata; secondary
>> Director de/activation mechanisms; redundant storage possibility; cannot
>> be considered a High Availability Solution. I will undergo a laboratory
>> on that.
> 
> It is not HA because the jobs that have been running on the failed
> server cannot be continued.

In fact, this is not even a RPO failure, because the largest chances are you 
still have the original data to perform a new backup.
But if it is the case, we would just accept that it is impossible to have 
Bacula HA at this moment. 

Regards,
-- 
MSc Heitor Faria 
CEO Bacula LATAM 
mobile1: + 1 909 655-8971 
mobile2: + 55 61 98268-4220 
[ https://www.linkedin.com/in/msc-heitor-faria-5ba51b3 ] 
[ http://www.bacula.com.br/ ] 

América Latina 
[ http://bacula.lat/ | bacula.lat ] | [ http://www.bacula.com.br/ | 
bacula.com.br ]


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Gary R. Schmidt]

On 23/04/2019 21:50, Heitor Faria wrote:

Hello Radoslaw,

I meditated a lot about this topic, and just to keep it short I will 
resume my conclusions:


1. HA means single points of failure elimination, reliable crossover and 
failure detection. I don't see how having two replicated always on 
Directors (perhaps with the same Director Name); replicated job and 
client configurations; replicated backup data and metadata; secondary 
Director de/activation mechanisms; redundant storage possibility; cannot 
be considered a High Availability Solution. I will undergo a laboratory 
on that.


It is not HA because the jobs that have been running on the failed 
server cannot be continued.


On a HA system, failure doesn't necessarily mean all prior state is lost.

On the VAXClusters[1] I used to wrangle back in the 1980s (where 
everything was automatically checkpointed), when a machine went down the 
load balancer just switched you across to one of the other machines  and 
things continued on from the last checkpoint.  In Bacula terms, the file 
that was being backed up at the time of failure may have to be redone, 
not the entire job.


Cluster failover of Bacula jobs requires a re-start of all 
incomplete/failed jobs, all prior state has to be discarded, so if you 
are 99% through a several terabyte backup, that backup has to be run 
again, completely.


Which means it's DR, we start with effectively a clean slate and some 
context from some time in the past.


Cheers,
GaryB-)

1 - That was proper clusters, that was, not the half-arsed crap that 
lusers call clustering these days.



___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Hello Radoslaw, 

I meditated a lot about this topic, and just to keep it short I will resume my 
conclusions: 

1. HA means single points of failure elimination, reliable crossover and 
failure detection. I don't see how having two replicated always on Directors 
(perhaps with the same Director Name); replicated job and client 
configurations; replicated backup data and metadata; secondary Director 
*SCHEDULE de/activation mechanisms; redundant storage possibility; cannot be 
considered a High Availability Solution. I will undergo a laboratory on that. 
2. Backup data replication RPO is a detail that can be improved and usually 
determined by own Bacula current limitations. 
3. Every big data center application usually has their native cluster 
mechanism, so DRBD+whatever cannot be the considered the silver bullet. In 
fact, IMHO, it is a overkill to use your proposal to replicate the Director 
service, and adds a lot of complexity. 

Regards, 
-- 

MSc Heitor Faria 
CEO Bacula LATAM 
mobile1: + 1 909 655-8971 
mobile2: + 55 61 98268-4220 
[ https://www.linkedin.com/in/msc-heitor-faria-5ba51b3 ] 
[ http://www.bacula.com.br/ ] 

América Latina 
[ http://bacula.lat/ | bacula.lat ] | [ http://www.bacula.com.br/ | 
bacula.com.br ] 



___ 
Bacula-users mailing list 
Bacula-users@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/bacula-users 
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Hello Radoslaw, 

I meditated a lot about this topic, and just to keep it short I will resume my 
conclusions: 

1. HA means single points of failure elimination, reliable crossover and 
failure detection. I don't see how having two replicated always on Directors 
(perhaps with the same Director Name); replicated job and client 
configurations; replicated backup data and metadata; secondary Director 
de/activation mechanisms; redundant storage possibility; cannot be considered a 
High Availability Solution. I will undergo a laboratory on that. 
2. Backup data replication RPO is a detail that can be improved and usually 
determined by own Bacula current limitations. 
3. Every big data center application usually has their native cluster 
mechanism, so DRBD+whatever cannot be the considered the silver bullet. In 
fact, IMHO, it is a overkill to use your proposal to replicate the Director 
service, and adds a lot of complexity. 

Regards, 
-- 

MSc Heitor Faria 
CEO Bacula LATAM 
mobile1: + 1 909 655-8971 
mobile2: + 55 61 98268-4220 
[ https://www.linkedin.com/in/msc-heitor-faria-5ba51b3 ] 
[ http://www.bacula.com.br/ ] 

América Latina 
[ http://bacula.lat/ | bacula.lat ] | [ http://www.bacula.com.br/ | 
bacula.com.br ] 
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Radosław Korzeniewski]

Hello,

pt., 19 kwi 2019 o 20:25 Heitor Faria  napisał(a):

> Hello Radoslaw,
>
> Hello,
>
> pt., 19 kwi 2019 o 13:28 Heitor Faria  napisał(a):
>
>> Hello Radoslaw,
>>
>> Speaking of Bacula HA, I've been deploying a scenario with relative
>>> success.
>>> Primary Director & SD have copy jobs routines to a Secondary Remote SD
>>> that also has an independent working Director.
>>
>>
>> It sounds to me as a Disaster Recovery solution and absolutely no High
>> Availability.
>>
>> Is there any difference?
>>
>
> The difference is HUGE
>
>
>> For me there are two Disaster Recovery categories, Backup and
>> Replication. HA falls in the second category.
>>
>
> Disaster Recovery is a part of more general Business Continuity Plan. BCP
> describes what to do when something wrong happens to our business and
> consist of a number of procedures and performances executed in hard times.
> DR focus on recovery only.
> What is a disaster? Do a single disk failure is a disaster? Do a single
> network adapter or single server or single rack failures are disasters? Do
> a single Datacenter failure is a disaster? And what are availability
> levels? How does it compares?
>
> We were discussing concepts, used by Dell/EMC Certification and the best
> scientific literacture on the topic.
>

I'm using concepts from Veritas (i.e. Resilience Enterprise) and its
Certification, so  :)
Update: I checked linked paper and it uses concepts I see as a disaster
recovery solution and what a surprise it names it as Disaster Recovery...
(check below)


> I don't see how policies, use cases or plans affect that.
> Anyway, having director redundancy, as in the original proposal, allows
> Backup and Restore Services HA,
>

Yes, the HA is different then DR. Thank you.


> since both would be almost always online (even lacking the failed running
> jobs redistribution, as pointed by Dimitri).
>
> First of all a backup is one of the services managed by any IT
> departments. So as a service it should run without problems and maintain a
> good availability level. Just take a look for maintaining Oracle RDBMS with
> the best backup and recovery solution using Bacula Oracle SBT Plugin. With
> this plugin you can setup a two kinds of backups: online database files
> backup and archived logs backups. Together allow for perfect
> Point-In-Time-Recovery. The first one can be executed once a day, once a
> week, etc. but the second one should be executed as frequent as it is
> possible to maintain the best RPO possible.
>
> I see this as the Disaster Recovery levels or dimensions [T. Wood, E.
> Cecchet, K. K. Ramakrishnan, P. J. Shenoy, J. E. van der Merwe, and A.
> Venkataramani, “Disaster Recovery as a Cloud Service: Economic Benefits &
> Deployment Challenges.,” *HotCloud*, vol. 10, pp. 8–15, 2010.]:
>

I checked this paper and it prove my point of view on what DR is and what
is HA... in every single word. In a few minutes I thought that all I
learned about High Availability and Disaster Recovery in my >20 years of
Enterprise experience was redefined backwards. :) I see, not yet.

What I see in your post: every time you describe a great DR solution you
does not name it DR but you name it HA which is not true.

"Speaking of Bacula HA, I've been deploying a scenario with relative
success.
Primary Director & SD have copy jobs routines to a Secondary Remote SD..."


>
> Data level: Security of application data
> System level: Reducing recovery time as short as possible
> Application level: Application continuity
>


> To achieve this you have to maintain a backup service as highly available
> as possible with eliminating SPOF (single point in failure). For above
> breakdowns you have to multiple components, i.e. bring two network
> adapters, create a RAID, create a cluster, put every cluster node in a
> separate rack, etc. All this allow you to achieve a High Availability
> service with zero data loss in case of failover. For Datacenter it is
> always a different story! If you need to failover a datacenter then you
> always lost your data! This is because Bacula replication is asynchronous,
> so it is not possible to have up to date archives on both sides at any
> given time.
>
> You will always have a lag. On the other hand, you can implement a block
> level replication which could be synchronous, but this kind of solution do
> not work with tapes and when synchronous it has a huge impact on
> performance. In most cases synchronous block level replication on large
> scale and long distances requires a lot of cash! Synchronous block level
> replication should never be used as a part of Backup DR solution, because a
> single block corruption can leads to whole filesystem corruption and lost
> of archive volumes! So, back to asynchronous Bacula replication - did I
> mention it will create a lag, so your RPO > 0. :)
>
> This is true for most recent backups, but there are ways of mitigating
> this (redundant jobs, simultaneous backup to two different jobs 

Re: [Bacula-users] Doubts about Bacula

[Radosław Korzeniewski]

Hello,

pt., 19 kwi 2019 o 19:24 Dimitri Maziuk via Bacula-users <
bacula-users@lists.sourceforge.net> napisał(a):

> On 4/19/19 11:56 AM, Radosław Korzeniewski wrote:
>
> > When you implement Bacula in the shared storage cluster, you can failover
> > backup service from node to node in any direction in just a seconds. Your
> > shared storage cluster can do it for you automatically as soon as it
> check
> > that a service is unavailable.
>
> ...as long as you are not actually using it, as in you don't have a
> backup running.
>
> When you fail over during (per Murphy's Law: 99% into) a running backup,
> the above is no longer entirely correct. You have to restart the backup,
> from scratch, at a different point in time, and probably having wasted
> the tapes written by this point as well.
>

When your Bacula server crash or become unavailable you "... have to
restart the backup,
from scratch, at a different point in time, and probably having wasted
the tapes written by this point as well ... " but you have no available
replacement and all your future
backups scheduled after an outage will not execute at all.


>
> If you define your service as "having a usable backup, on schedule", you
> can't fail that service over "in seconds".
>
>
No, you cannot define your service like that. Having a "usable" backup
cannot be proved until tested. So it has a lot of other implications as
well.


> Don't get me wrong, I have any number of HA pairs that work exactly as
> you describe, with configs, spools, and upload areas on DRBD, and so on.
> Just not bacula.
>

I'm not forcing anybody to use cluster HA solution for his backup system.
>From one point of view it is a waste of money. But from the other point of
view it is a justified insurance. Everyone have to choose what he needs and
can afford it.

But the High Availability is not the same as Disaster Recovery solution.
Having HA is not the same in any function as having DR.

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Jari Fredriksson]

Tilman Schmidt kirjoitti 20.4.2019 16:59:


On Sat, Apr 20, 2019, at 15:44, Michael Plante wrote:

On Tue, Apr 16, 2019, 09:11 Jari Fredriksson  wrote:

I use 4.6 GB for my Volumes, and my storage size is a 8 TB Archive Disk
(SMR). That has a historical reason as once upon a time I stored them 
to

DVD-RW.

Copying to DVD seems like a good idea to me.


It isn't. My experience with the long-term stability of data written to 
DVDs was rather sobering. The media regularly turned out not to be 
readable anymore when I needed them. Conclusion: Don't count on DVDs if 
you value your data.


This. I one pool for normal jobs and another copy pool for copy of fulls 
and incrementals. On a hard disk. DVD was *slow*, *impractical* and not 
*reliable*.



--
ja...@iki.fi


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Tilman Schmidt]

On Sat, Apr 20, 2019, at 15:44, Michael Plante wrote:
> On Tue, Apr 16, 2019, 09:11 Jari Fredriksson  wrote:
>> 
>> I use 4.6 GB for my Volumes, and my storage size is a 8 TB Archive Disk
>>  (SMR). That has a historical reason as once upon a time I stored them to 
>>  DVD-RW.
> 
> Copying to DVD seems like a good idea to me.

It isn't. My experience with the long-term stability of data written to DVDs 
was rather sobering. The media regularly turned out not to be readable anymore 
when I needed them. Conclusion: Don't count on DVDs if you value your data.

--
Tilman Schmidt
til...@imap.cc

___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Michael Plante]

Hi Jari,


On Tue, Apr 16, 2019, 09:11 Jari Fredriksson  wrote:

>
>
> I use 4.6 GB for my Volumes, and my storage size is a 8 TB Archive Disk
> (SMR). That has a historical reason as once upon a time I stored them to
> DVD-RW.
>

Copying to DVD seems like a good idea to me.  Why did you stop, and did you
replace that solution with an alternative?

Thanks,
Michael




>
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Just in time: I know you felt out of the chair when I said replication RPO is 
equal to one. I explain. 
I greatly diverge of the RPO most used industry equation. I think it is 
misleading and created to golden Replication products: 

RPO = 1 / Backup Frequency 

It only considers the need for the most rescent data restoration. 
The problem is, data loss might happen prior last backup, replication versions 
or any time in the past (e.g. a non-detected data corruption or malicious 
change). So a better equation should be: 

RPO = 1 / Backup Frequency * Number of Retained Backup Versions 

Usually replication only saves one backup version, so that's why backup is 
still necessary. Data can change between replications, and this can cause data 
loss for 99,99% of the applications. 

Regards, 

> From: "Heitor Faria" 
> To: "Radosław Korzeniewski" 
> Cc: "bacula-users" 
> Sent: Friday, April 19, 2019 3:25:09 PM
> Subject: Re: [Bacula-users] Doubts about Bacula

> Hello Radoslaw,

>> Hello,

>> pt., 19 kwi 2019 o 13:28 Heitor Faria < [ mailto:hei...@bacula.com.br |
>> hei...@bacula.com.br ] > napisał(a):

>>> Hello Radoslaw,

>>>>> Speaking of Bacula HA, I've been deploying a scenario with relative 
>>>>> success.
>>>>> Primary Director & SD have copy jobs routines to a Secondary Remote SD 
>>>>> that also
>>>>> has an independent working Director.
>>>> It sounds to me as a Disaster Recovery solution and absolutely no High
>>>> Availability.

>>> Is there any difference?

>> The difference is HUGE

>>> For me there are two Disaster Recovery categories, Backup and Replication. 
>>> HA
>>> falls in the second category.

>> Disaster Recovery is a part of more general Business Continuity Plan. BCP
>> describes what to do when something wrong happens to our business and consist
>> of a number of procedures and performances executed in hard times. DR focus 
>> on
>> recovery only.
>> What is a disaster? Do a single disk failure is a disaster? Do a single 
>> network
>> adapter or single server or single rack failures are disasters? Do a single
>> Datacenter failure is a disaster? And what are availability levels? How does 
>> it
>> compares?

> We were discussing concepts, used by Dell/EMC Certification and the best
> scientific literacture on the topic. I don't see how policies, use cases or
> plans affect that.
> Anyway, having director redundancy, as in the original proposal, allows Backup
> and Restore Services HA, since both would be almost always online (even 
> lacking
> the failed running jobs redistribution, as pointed by Dimitri).

>> First of all a backup is one of the services managed by any IT departments. 
>> So
>> as a service it should run without problems and maintain a good availability
>> level. Just take a look for maintaining Oracle RDBMS with the best backup and
>> recovery solution using Bacula Oracle SBT Plugin. With this plugin you can
>> setup a two kinds of backups: online database files backup and archived logs
>> backups. Together allow for perfect Point-In-Time-Recovery. The first one can
>> be executed once a day, once a week, etc. but the second one should be 
>> executed
>> as frequent as it is possible to maintain the best RPO possible.

> I see this as the Disaster Recovery levels or dimensions [T. Wood, E. Cecchet,
> K. K. Ramakrishnan, P. J. Shenoy, J. E. van der Merwe, and A. Venkataramani,
> “Disaster Recovery as a Cloud Service: Economic Benefits & Deployment
> Challenges.,” HotCloud , vol. 10, pp. 8–15, 2010.]:

> Data level: Security of application data
> System level: Reducing recovery time as short as possible
> Application level: Application continuity

>> To achieve this you have to maintain a backup service as highly available as
>> possible with eliminating SPOF (single point in failure). For above 
>> breakdowns
>> you have to multiple components, i.e. bring two network adapters, create a
>> RAID, create a cluster, put every cluster node in a separate rack, etc. All
>> this allow you to achieve a High Availability service with zero data loss in
>> case of failover. For Datacenter it is always a different story! If you need 
>> to
>> failover a datacenter then you always lost your data! This is because Bacula
>> replication is asynchronous, so it is not possible to have up to date 
>> archives
>> on both sides at any given time.

>> You will always have a lag. On the other hand, you can implement a block 
>> level
>> replication which could be synchronous, but this kind of solution do

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Hello Radoslaw, 

> Hello,

> pt., 19 kwi 2019 o 13:28 Heitor Faria < [ mailto:hei...@bacula.com.br |
> hei...@bacula.com.br ] > napisał(a):

>> Hello Radoslaw,

 Speaking of Bacula HA, I've been deploying a scenario with relative 
 success.
 Primary Director & SD have copy jobs routines to a Secondary Remote SD 
 that also
 has an independent working Director.
>>> It sounds to me as a Disaster Recovery solution and absolutely no High
>>> Availability.

>> Is there any difference?

> The difference is HUGE

>> For me there are two Disaster Recovery categories, Backup and Replication. HA
>> falls in the second category.

> Disaster Recovery is a part of more general Business Continuity Plan. BCP
> describes what to do when something wrong happens to our business and consist
> of a number of procedures and performances executed in hard times. DR focus on
> recovery only.
> What is a disaster? Do a single disk failure is a disaster? Do a single 
> network
> adapter or single server or single rack failures are disasters? Do a single
> Datacenter failure is a disaster? And what are availability levels? How does 
> it
> compares?

We were discussing concepts, used by Dell/EMC Certification and the best 
scientific literacture on the topic. I don't see how policies, use cases or 
plans affect that. 
Anyway, having director redundancy, as in the original proposal, allows Backup 
and Restore Services HA, since both would be almost always online (even lacking 
the failed running jobs redistribution, as pointed by Dimitri). 

> First of all a backup is one of the services managed by any IT departments. So
> as a service it should run without problems and maintain a good availability
> level. Just take a look for maintaining Oracle RDBMS with the best backup and
> recovery solution using Bacula Oracle SBT Plugin. With this plugin you can
> setup a two kinds of backups: online database files backup and archived logs
> backups. Together allow for perfect Point-In-Time-Recovery. The first one can
> be executed once a day, once a week, etc. but the second one should be 
> executed
> as frequent as it is possible to maintain the best RPO possible.

I see this as the Disaster Recovery levels or dimensions [T. Wood, E. Cecchet, 
K. K. Ramakrishnan, P. J. Shenoy, J. E. van der Merwe, and A. Venkataramani, 
“Disaster Recovery as a Cloud Service: Economic Benefits & Deployment 
Challenges.,” HotCloud , vol. 10, pp. 8–15, 2010.]: 

Data level: Security of application data 
System level: Reducing recovery time as short as possible 
Application level: Application continuity 

> To achieve this you have to maintain a backup service as highly available as
> possible with eliminating SPOF (single point in failure). For above breakdowns
> you have to multiple components, i.e. bring two network adapters, create a
> RAID, create a cluster, put every cluster node in a separate rack, etc. All
> this allow you to achieve a High Availability service with zero data loss in
> case of failover. For Datacenter it is always a different story! If you need 
> to
> failover a datacenter then you always lost your data! This is because Bacula
> replication is asynchronous, so it is not possible to have up to date archives
> on both sides at any given time.

> You will always have a lag. On the other hand, you can implement a block level
> replication which could be synchronous, but this kind of solution do not work
> with tapes and when synchronous it has a huge impact on performance. In most
> cases synchronous block level replication on large scale and long distances
> requires a lot of cash! Synchronous block level replication should never be
> used as a part of Backup DR solution, because a single block corruption can
> leads to whole filesystem corruption and lost of archive volumes! So, back to
> asynchronous Bacula replication - did I mention it will create a lag, so your
> RPO > 0. :)

This is true for most recent backups, but there are ways of mitigating this 
(redundant jobs, simultaneous backup to two different jobs (if ever 
developed)). 
Syncronous or Asyncronous replication will always have = 1 RPO, the only 
difference is the data outdating. 

>>> In any HA solution you would assure that your services are running the 
>>> highest
>>> uptime possible and this kind of solution in most cases is implemented with
>>> clusters. In this case you can loose currently uncommitted data (running 
>>> jobs)
>>> but your services are ready to proceed next jobs as soon as possible.

>> I disagree a little bit. Replication purpose is provide the better possible 
>> RTO.

> So, lets compare:
> Shared storage Cluster HA: RPO - no data loss; RTO - automatic failover, 
> seconds
> from failure detection to recovery;
> Asynchronous Replication in Bacula: RPO - hours, minutes the best, in most 
> cases
> single day; RTO - manual switchover - hours;

Disagree. Director redudancy provides near zero RTO to the backup and restore 

Re: [Bacula-users] Doubts about Bacula

[Dimitri Maziuk via Bacula-users]

On 4/19/19 11:56 AM, Radosław Korzeniewski wrote:

> When you implement Bacula in the shared storage cluster, you can failover
> backup service from node to node in any direction in just a seconds. Your
> shared storage cluster can do it for you automatically as soon as it check
> that a service is unavailable.

...as long as you are not actually using it, as in you don't have a
backup running.

When you fail over during (per Murphy's Law: 99% into) a running backup,
the above is no longer entirely correct. You have to restart the backup,
from scratch, at a different point in time, and probably having wasted
the tapes written by this point as well.

If you define your service as "having a usable backup, on schedule", you
can't fail that service over "in seconds".

Don't get me wrong, I have any number of HA pairs that work exactly as
you describe, with configs, spools, and upload areas on DRBD, and so on.
Just not bacula.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Radosław Korzeniewski]

Hello,

pt., 19 kwi 2019 o 13:28 Heitor Faria  napisał(a):

> Hello Radoslaw,
>
> Speaking of Bacula HA, I've been deploying a scenario with relative
>> success.
>> Primary Director & SD have copy jobs routines to a Secondary Remote SD
>> that also has an independent working Director.
>
>
> It sounds to me as a Disaster Recovery solution and absolutely no High
> Availability.
>
> Is there any difference?
>

The difference is HUGE


> For me there are two Disaster Recovery categories, Backup and Replication.
> HA falls in the second category.
>

Disaster Recovery is a part of more general Business Continuity Plan. BCP
describes what to do when something wrong happens to our business and
consist of a number of procedures and performances executed in hard times.
DR focus on recovery only.
What is a disaster? Do a single disk failure is a disaster? Do a single
network adapter or single server or single rack failures are disasters? Do
a single Datacenter failure is a disaster? And what are availability
levels? How does it compares?

First of all a backup is one of the services managed by any IT departments.
So as a service it should run without problems and maintain a good
availability level. Just take a look for maintaining Oracle RDBMS with the
best backup and recovery solution using Bacula Oracle SBT Plugin. With this
plugin you can setup a two kinds of backups: online database files backup
and archived logs backups. Together allow for perfect
Point-In-Time-Recovery. The first one can be executed once a day, once a
week, etc. but the second one should be executed as frequent as it is
possible to maintain the best RPO possible. To achieve this you have to
maintain a backup service as highly available as possible with eliminating
SPOF (single point in failure). For above breakdowns you have to multiple
components, i.e. bring two network adapters, create a RAID, create a
cluster, put every cluster node in a separate rack, etc. All this allow you
to achieve a High Availability service with zero data loss in case of
failover. For Datacenter it is always a different story! If you need to
failover a datacenter then you always lost your data! This is because
Bacula replication is asynchronous, so it is not possible to have up to
date archives on both sides at any given time. You will always have a lag.
On the other hand, you can implement a block level replication which could
be synchronous, but this kind of solution do not work with tapes and when
synchronous it has a huge impact on performance. In most cases synchronous
block level replication on large scale and long distances requires a lot of
cash! Synchronous block level replication should never be used as a part of
Backup DR solution, because a single block corruption can leads to whole
filesystem corruption and lost of archive volumes! So, back to asynchronous
Bacula replication - did I mention it will create a lag, so your RPO > 0.
:)

> In any HA solution you would assure that your services are running the
> highest uptime possible and this kind of solution in most cases is
> implemented with clusters. In this case you can loose currently uncommitted
> data (running jobs) but your services are ready to proceed next jobs as
> soon as possible.
>
> I disagree a little bit. Replication purpose is provide the better
> possible RTO.
>

So, lets compare:
Shared storage Cluster HA: RPO - no data loss; RTO - automatic failover,
seconds from failure detection to recovery;
Asynchronous Replication in Bacula: RPO - hours, minutes the best, in most
cases single day; RTO - manual switchover - hours;

High Availability solutions focus on Service levels and are not designed to
handle disasters. Disaster Recovery solutions focus on disasters and are
not designed for fast and easy backup service switchover. Different
solutions for different purposes. The Enterprise want them both!

For obvious reasons, Bacula cannot re-distribute a failed backup job yet
> (perhaps never will), but I don't think it is necessarelly a problem for
> Replication.
>
> HA implementation in Bacula is extremely straightforward when using a
> shared storage clustering solution.
>
>
>> Both director can access the Secondary SD.
>> An Admin Job with a Shell Script daily bscans all volumes in to the
>> Secondary Director and its catalog.
>> All bscanned volumes comes with the Archived status, so they are
>> basically Read-Only.
>> Advantage: you can restore jobs from both environments, any time. =>
>> http://bacula.us/bacula-server-and-backups-replication-for-high-availability/
>> Perhaps, a "bscan all" bconsole command would be a nice feature to sync
>> all disk based volumes to catalog and improve the proccess a little bit
>> more.
>>
>
> This is a Disaster Recovery solution. A One-Way Failover. :)
>
> Pot8to, potato. =)
> From Bacula perspective that's what we have today.
>

What?
When you implement Bacula in the shared storage cluster, you can failover
backup service from node to node in any 

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Hello Radoslaw, 

>> Speaking of Bacula HA, I've been deploying a scenario with relative success.
>> Primary Director & SD have copy jobs routines to a Secondary Remote SD that 
>> also
>> has an independent working Director.
> It sounds to me as a Disaster Recovery solution and absolutely no High
> Availability.

Is there any difference? 
For me there are two Disaster Recovery categories, Backup and Replication. HA 
falls in the second category. 

> In any HA solution you would assure that your services are running the highest
> uptime possible and this kind of solution in most cases is implemented with
> clusters. In this case you can loose currently uncommitted data (running jobs)
> but your services are ready to proceed next jobs as soon as possible.

I disagree a little bit. Replication purpose is provide the better possible 
RTO. 
For obvious reasons, Bacula cannot re-distribute a failed backup job yet 
(perhaps never will), but I don't think it is necessarelly a problem for 
Replication. 
> HA implementation in Bacula is extremely straightforward when using a shared
> storage clustering solution.

>> Both director can access the Secondary SD.
>> An Admin Job with a Shell Script daily bscans all volumes in to the Secondary
>> Director and its catalog.
>> All bscanned volumes comes with the Archived status, so they are basically
>> Read-Only.
>> Advantage: you can restore jobs from both environments, any time. => [
>> http://bacula.us/bacula-server-and-backups-replication-for-high-availability/
>>  |
>> http://bacula.us/bacula-server-and-backups-replication-for-high-availability/
>>  ]
>> Perhaps, a "bscan all" bconsole command would be a nice feature to sync all 
>> disk
>> based volumes to catalog and improve the proccess a little bit more.

> This is a Disaster Recovery solution. A One-Way Failover. :)

Pot8to, potato. =) 
>From Bacula perspective that's what we have today. 
A surprising large amount of my customers wants Bacula HA but do not want to 
use clusters or 3rd party solutions. Don't know the reason for that phenomenom. 

Regards, 
-- 

MSc Heitor Faria 
CEO Bacula LATAM 
mobile1: + 1 909 655-8971 
mobile2: + 55 61 98268-4220 
[ https://www.linkedin.com/in/msc-heitor-faria-5ba51b3 ] 
[ http://www.bacula.com.br/ ] 

América Latina 
[ http://bacula.lat/ | bacula.lat ] | [ http://www.bacula.com.br/ | 
bacula.com.br ] 
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Radosław Korzeniewski]

Hello,

wt., 16 kwi 2019 o 17:29 Josh Fisher  napisał(a):

>
> On 4/16/2019 10:45 AM, Dmitri Maziuk via Bacula-users wrote:
> > On Mon, 15 Apr 2019 23:24:10 -0300
> > Marcio Demetrio Bacci  wrote:
> >
> >> 5. Currently the OS and Backup disks are on the same DRBD volume, so
> >> would it be better to put the OS disk out of the DRBD volume? (the VM
> >> has frequently crashing what makes me think that excessive writing on
> >> the disk may be impacting the OS)
> > I would put everything out of drbd volume because quite frankly I don't
> > see the point. I don't think you can fail over in a middle of a backup,
> > and without that, why not just put OS on NFS? -- or ZFS and send
> > incremental snapshot as part of your manual failover. Using drbd for
> > backup storage is just a waste of disk.
>
>
> Running jobs will fail,


Assuming jobs fail because we failover the Bacula Director service, right?


> but the automated "Reschedule On Error" feature
> allows restarting them after the fail-over.


Well, no. Rescheduling is based on actual job thread running on Bacula
Director. Any Director restart will stop this feature for a particular
jobid!

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Radosław Korzeniewski]

Hello,

wt., 16 kwi 2019 o 17:15 Heitor Faria  napisał(a):

> Hello All,
>
> >> 5. Currently the OS and Backup disks are on the same DRBD volume, so
> >> would it be better to put the OS disk out of the DRBD volume? (the VM
> >> has frequently crashing what makes me think that excessive writing on
> >> the disk may be impacting the OS)
> >
> > I would put everything out of drbd volume because quite frankly I don't
> > see the point. I don't think you can fail over in a middle of a backup,
> > and without that, why not just put OS on NFS? -- or ZFS and send
> > incremental snapshot as part of your manual failover. Using drbd for
> > backup storage is just a waste of disk.
>
> Speaking of Bacula HA, I've been deploying a scenario with relative
> success.
> Primary Director & SD have copy jobs routines to a Secondary Remote SD
> that also has an independent working Director.


It sounds to me as a Disaster Recovery solution and absolutely no High
Availability. In any HA solution you would assure that your services are
running the highest uptime possible and this kind of solution in most cases
is implemented with clusters. In this case you can loose currently
uncommitted data (running jobs) but your services are ready to proceed next
jobs as soon as possible.

HA implementation in Bacula is extremely straightforward when using a
shared storage clustering solution.


> Both director can access the Secondary SD.
> An Admin Job with a Shell Script daily bscans all volumes in to the
> Secondary Director and its catalog.
> All bscanned volumes comes with the Archived status, so they are basically
> Read-Only.
> Advantage: you can restore jobs from both environments, any time. =>
> http://bacula.us/bacula-server-and-backups-replication-for-high-availability/
> Perhaps, a "bscan all" bconsole command would be a nice feature to sync
> all disk based volumes to catalog and improve the proccess a little bit
> more.
>

This is a Disaster Recovery solution. A One-Way Failover. :)

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Kern Sibbald]

Hello,

Please see my comment below:

On 4/16/19 8:15 AM, Josip Deanovic wrote:

On Monday 2019-04-15 23:24:10 Marcio Demetrio Bacci wrote:

I have some doubts about Bacula, however I did not find answers on the
Internet or in the books for the following doubts:

1. Is there any problem in using Bacula virtualized? (I didn't find
anything saying otherwise)

No.
I have several setups on vmware and kvm. Even few on raspberry-pi and
they are all running for at least 5 years, some of them 10+.


2. Is there any restriction on mounting the Bacula VM on a DRBD volume
in the hypervisor. In this VM I will implement ZFS deduplication for my
backups?

No. As long as Bacula can use the file system as usual, Bacula will not
be affected by the fact you are using DRBD as it just provides another
block device you are using for your file system of choice (in your case
ZFS).

But you might want to read some articles on the DRBD + ZFS setup if you
haven't done that already.
E.g. http://cedric.dufour.name/blah/IT/ZfsOnTopOfDrbd.html


3. Is there any limitation on the size of Backups with Bacula Community
version? (I did not find information about any limitations)

No. Bacula Systems is kind enough to not impose such limits on Bacula
Community version and it was never a case.


What you said is perfectly correct.  However it seems to imply that 
Bacula Systems may have some control over the Community version, which 
is not the case.


Bacula Systems was created by me, and as Chairman of the Board of Bacula 
Systems, I can assure you that Bacula Systems does not impose anything 
on the Community version, and it never will. Bacula Systems can co-exist 
with the Community version because they have the financial means to 
create differentiating features that are attractive to Enterprise 
customers.  Ultimately these differentiating features are over time 
backported into the Community version -- so in effect Bacula Systems 
rather than "imposing limits" on the Community version has been over the 
years adding a lot of new functionality to the community version.


As an aside: Bacula Systems, contrary to virtually all other commercial 
vendors, does not even limit or charge its customers for the size of the 
backup.  The support fees are the charged on the complexity (and thus 
the support load) as best as is possible (primarily on the number of 
clients and number of plugins).


Best regards,

Kern




4. Having a few jobs with 300 GB or more, though I set up my volumes on
Bacula with 100 GB, so would you recommend increasing the size of the
volumes to 200 GB or more?

I prefer to keep them at 10G so that I can maintain them easier in case
I need to deal with the volumes manually.


5. Currently the OS and Backup disks are on the same DRBD volume, so
would it be better to put the OS disk out of the DRBD volume? (the VM
has frequently crashing what makes me think that excessive writing on
the disk may be impacting the OS)

Generally, it is good idea to keep OS and the data separated.
That way you can optimize its devices differently performance and
security-wise.

But if your DRBD is the only thing that gives you redundancy then it's
better to keep them both on the DRBD.

However, the crashing VM is really bad problem and is not something
that should be ignored or considered as nuisance.
You should attend to solving this problem before proceeding with
improvements of other systems that rely on that VM and its stability.

Good luck.


Regards!





___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Dimitri Maziuk via Bacula-users]

On 4/16/19 1:22 PM, Josip Deanovic wrote:

> The usual way to do it is a shared storage.
> Servers would need to be able to connect to the storage and see the
> exported LUN over fibre channel, iSCSI or similar protocol.

And what I was saying is that at this point DRBD would be very low on my
list of shared storage options for this application.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

On Tuesday 2019-04-16 12:40:02 Dimitri Maziuk via Bacula-users wrote:
> On 4/16/19 10:04 AM, Josip Deanovic wrote:
> > NFS and DRBD are not really comparable that way.
> 
> The easy way you migrate a running VM from one host to another is to
> have the image on an NFS mounted on both hosts.

Yes, that's one way to do it.

> The hard way involves copying the actual image file, however, if you use
> ZFS you may get away with only copying a small incremental snapshot.

Copying the image around is the most inconvenient way to do it.

> Last but not least, you can set it up on DRBD and make sure you get your
> HA stack set up to migrate everything over correctly. With all the
> network-controlled power outlets and the rest of the bloat you need to
> make corosync/pacemaker run.

Yes, that's somewhat complicated way to do it.


The usual way to do it is a shared storage.
Servers would need to be able to connect to the storage and see the
exported LUN over fibre channel, iSCSI or similar protocol.
If no simpler solutions are available, a locking mechanism (usually a
component of a cluster infrastructure) would need to be employed to
ensure that only one process is using the LUN at any time to avoid
corruption.

> Personally I believe in simple stupid; all my VMs live behind door
> number 1.

I totally agree that solutions should be as simple as possible.
But not at the cost of stability and data integrity.


Regards!

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

On Tuesday 2019-04-16 12:28:45 Dimitri Maziuk via Bacula-users wrote:
> On 4/16/19 10:27 AM, Josh Fisher wrote:
> > Running jobs will fail, but the automated "Reschedule On Error"
> > feature
> > allows restarting them after the fail-over. Also, fail-over doesn't
> > affect scheduled jobs that haven't started yet at the time of
> > fail-over. Putting the OS on DRBD and running in a VM (or container)
> > allows continuation of backup services without operator intervention.
> > What is wrong with that?
> 
> Nothing, I just doubt migrating the VM itself is all that seamless and
> stable without operator intervention. Admittedly, I have not played with
> that in years... but last I looked if you actually *failed* without an
> orderly VM shutdown, booting it up on the other node was a crap shoot.

It's working just fine even with opensource technology for years.

I used live migration of KVM virtual machines in 2010 and it worked
without problems.
While working in the virtual machine using ssh, a user wouldn't even
notice that the virtual machine was migrated.

The only problem for was a particular cluster component that was
unstable.

RHEV (RedHat Enterprise Virtualization) or oVirt solved that by
introducing a solution that didn't relay on complex and unstable
cluster components.


Regards!

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Dimitri Maziuk via Bacula-users]

Not sure how this happened:

> The easy way you migrate a running from one host to another VM is have

-- it was meant to be "a running VM from one host to another".

8-\ boggle
-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Dimitri Maziuk via Bacula-users]

On 4/16/19 10:04 AM, Josip Deanovic wrote:

> NFS and DRBD are not really comparable that way.

The easy way you migrate a running from one host to another VM is have
the image on an NFS mounted on both hosts.

The hard way involves copying the actual image file, however, if you use
ZFS you may get away with only copying a small incremental snapshot.

Last but not least, you can set it up on DRBD and make sure you get your
HA stack set up to migrate everything over correctly. With all the
network-controlled power outlets and the rest of the bloat you need to
make corosync/pacemaker run.

Personally I believe in simple stupid; all my VMs live behind door number 1.
-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Dimitri Maziuk via Bacula-users]

On 4/16/19 10:27 AM, Josh Fisher wrote:
> 
> 
> Running jobs will fail, but the automated "Reschedule On Error" feature
> allows restarting them after the fail-over. Also, fail-over doesn't
> affect scheduled jobs that haven't started yet at the time of fail-over.
> Putting the OS on DRBD and running in a VM (or container) allows
> continuation of backup services without operator intervention. What is
> wrong with that?

Nothing, I just doubt migrating the VM itself is all that seamless and
stable without operator intervention. Admittedly, I have not played with
that in years... but last I looked if you actually *failed* without an
orderly VM shutdown, booting it up on the other node was a crap shoot.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

On Tuesday 2019-04-16 11:27:54 Josh Fisher wrote:
> On 4/16/2019 10:45 AM, Dmitri Maziuk via Bacula-users wrote:
> > I would put everything out of drbd volume because quite frankly I
> > don't
> > see the point. I don't think you can fail over in a middle of a
> > backup,
> > and without that, why not just put OS on NFS? -- or ZFS and send
> > incremental snapshot as part of your manual failover. Using drbd for
> > backup storage is just a waste of disk.
> 
> Running jobs will fail, but the automated "Reschedule On Error" feature
> allows restarting them after the fail-over. Also, fail-over doesn't
> affect scheduled jobs that haven't started yet at the time of fail-over.
> Putting the OS on DRBD and running in a VM (or container) allows
> continuation of backup services without operator intervention. What is
> wrong with that?

Nothing is wrong with that if one needs it and can afford it.

> I agree that putting volume files on DRBD is wasteful, since running
> jobs will always fail at fail-over, but putting just the OS on DRBD
> doesn't use much disk space, and it certainly isn't a waste when it
> reduces or eliminates operator intervention.

When used properly DRBD can ensure redundancy.

Often people want to have secondary backup and archives.

One can copy backup jobs or volumes to a remote site and archive
them at some point (my choice) but one can also chose to sync the
blocks of the underlying block device to a remote location which
could serve the purpose if the goal is to protect yourself from
hardware error on the primary site.


Regards!

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

Josip DeanovicOn Tuesday 2019-04-16 17:27:48  wrote:
> On Tuesday 2019-04-16 12:13:55 Heitor Faria wrote:
> > Speaking of Bacula HA, I've been deploying a scenario with relative
> > success. Primary Director & SD have copy jobs routines to a Secondary
> > Remote SD that also has an independent working Director. Both director
> > can access the Secondary SD. An Admin Job with a Shell Script daily
> > bscans all volumes in to the Secondary Director and its catalog. All
> > bscanned volumes comes with the Archived status, so they are basically
> > Read-Only. Advantage: you can restore jobs from both environments, any
> > time. =>
> > http://bacula.us/bacula-server-and-backups-replication-for-high-availa
> > b
> > ility/ Perhaps, a "bscan all" bconsole command would be a nice feature
> > to sync all disk based volumes to catalog and improve the proccess a
> > little bit more.
> 
> Have you tried to actually restore something from the secondary SD?
> 
> I am asking because I have reported some bugs related to bsr files
> but I don't remember the detail any more.
> 
> But since you are doing bscan on secondary SD it might not be affected
> by the bug I have mentioned.

Forgot to say that the bug I have mentioned was reported for the version
7.4 if I am not mistaken.

It could be fixed in newer versions.

Regards

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

On Tuesday 2019-04-16 12:13:55 Heitor Faria wrote:
> Speaking of Bacula HA, I've been deploying a scenario with relative
> success. Primary Director & SD have copy jobs routines to a Secondary
> Remote SD that also has an independent working Director. Both director
> can access the Secondary SD. An Admin Job with a Shell Script daily
> bscans all volumes in to the Secondary Director and its catalog. All
> bscanned volumes comes with the Archived status, so they are basically
> Read-Only. Advantage: you can restore jobs from both environments, any
> time. =>
> http://bacula.us/bacula-server-and-backups-replication-for-high-availab
> ility/ Perhaps, a "bscan all" bconsole command would be a nice feature
> to sync all disk based volumes to catalog and improve the proccess a
> little bit more.

Have you tried to actually restore something from the secondary SD?

I am asking because I have reported some bugs related to bsr files
but I don't remember the detail any more.

But since you are doing bscan on secondary SD it might not be affected
by the bug I have mentioned.


Regards!

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josh Fisher]

On 4/16/2019 10:45 AM, Dmitri Maziuk via Bacula-users wrote:

On Mon, 15 Apr 2019 23:24:10 -0300
Marcio Demetrio Bacci  wrote:


5. Currently the OS and Backup disks are on the same DRBD volume, so
would it be better to put the OS disk out of the DRBD volume? (the VM
has frequently crashing what makes me think that excessive writing on
the disk may be impacting the OS)

I would put everything out of drbd volume because quite frankly I don't
see the point. I don't think you can fail over in a middle of a backup,
and without that, why not just put OS on NFS? -- or ZFS and send
incremental snapshot as part of your manual failover. Using drbd for
backup storage is just a waste of disk.



Running jobs will fail, but the automated "Reschedule On Error" feature 
allows restarting them after the fail-over. Also, fail-over doesn't 
affect scheduled jobs that haven't started yet at the time of fail-over. 
Putting the OS on DRBD and running in a VM (or container) allows 
continuation of backup services without operator intervention. What is 
wrong with that?


I agree that putting volume files on DRBD is wasteful, since running 
jobs will always fail at fail-over, but putting just the OS on DRBD 
doesn't use much disk space, and it certainly isn't a waste when it 
reduces or eliminates operator intervention.





___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Heitor Faria]

Hello All,

>> 5. Currently the OS and Backup disks are on the same DRBD volume, so
>> would it be better to put the OS disk out of the DRBD volume? (the VM
>> has frequently crashing what makes me think that excessive writing on
>> the disk may be impacting the OS)
> 
> I would put everything out of drbd volume because quite frankly I don't
> see the point. I don't think you can fail over in a middle of a backup,
> and without that, why not just put OS on NFS? -- or ZFS and send
> incremental snapshot as part of your manual failover. Using drbd for
> backup storage is just a waste of disk.

Speaking of Bacula HA, I've been deploying a scenario with relative success.
Primary Director & SD have copy jobs routines to a Secondary Remote SD that 
also has an independent working Director. Both director can access the 
Secondary SD.
An Admin Job with a Shell Script daily bscans all volumes in to the Secondary 
Director and its catalog.
All bscanned volumes comes with the Archived status, so they are basically 
Read-Only. 
Advantage: you can restore jobs from both environments, any time. => 
http://bacula.us/bacula-server-and-backups-replication-for-high-availability/
Perhaps, a "bscan all" bconsole command would be a nice feature to sync all 
disk based volumes to catalog and improve the proccess a little bit more.

Regards,
-- 
MSc Heitor Faria 
CEO Bacula LATAM 
mobile1: + 1 909 655-8971 
mobile2: + 55 61 98268-4220 
[ https://www.linkedin.com/in/msc-heitor-faria-5ba51b3 ] 
[ http://www.bacula.com.br/ ] 

América Latina 
[ http://bacula.lat/ | bacula.lat ] | [ http://www.bacula.com.br/ | 
bacula.com.br ]


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

On Tuesday 2019-04-16 09:45:29 Dmitri Maziuk via Bacula-users wrote:
> On Mon, 15 Apr 2019 23:24:10 -0300
> 
> Marcio Demetrio Bacci  wrote:
> > 5. Currently the OS and Backup disks are on the same DRBD volume, so
> > would it be better to put the OS disk out of the DRBD volume? (the VM
> > has frequently crashing what makes me think that excessive writing on
> > the disk may be impacting the OS)
> 
> I would put everything out of drbd volume because quite frankly I don't
> see the point. I don't think you can fail over in a middle of a backup,
> and without that, why not just put OS on NFS? -- or ZFS and send
> incremental snapshot as part of your manual failover. Using drbd for
> backup storage is just a waste of disk.

NFS and DRBD are not really comparable that way.

DRBD is block level replication and you can achieve redundancy at the
block level.

NFS is a network file system which could be setup on top of the
DRBD provided block device and doesn't provide redundancy.


> I'd also try to run bacula in a container instead of VM at this point.
> but that's just me.

It all depends on his environment.

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Dmitri Maziuk via Bacula-users]

On Mon, 15 Apr 2019 23:24:10 -0300
Marcio Demetrio Bacci  wrote:

> 5. Currently the OS and Backup disks are on the same DRBD volume, so
> would it be better to put the OS disk out of the DRBD volume? (the VM
> has frequently crashing what makes me think that excessive writing on
> the disk may be impacting the OS)

I would put everything out of drbd volume because quite frankly I don't
see the point. I don't think you can fail over in a middle of a backup,
and without that, why not just put OS on NFS? -- or ZFS and send
incremental snapshot as part of your manual failover. Using drbd for
backup storage is just a waste of disk.

I'd also try to run bacula in a container instead of VM at this point.
but that's just me.
-- 
Dmitri Maziuk 


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josh Fisher]

On 4/15/2019 10:50 PM, Gary R. Schmidt wrote:

On 16/04/2019 12:24, Marcio Demetrio Bacci wrote:

...


2. Is there any restriction on mounting the Bacula VM on a DRBD 
volume in the hypervisor. In this VM I will implement ZFS 
deduplication for my backups?


I /think/ you are asking if Bacula can handle fail-over during backup?
Short answer is "no".  (I am willing to accept corrections on this, 
but AFAICS Bacula doesn't checkpoint its output.)



I would say "mostly", rather than "no".  On fail-over, running jobs will 
eventually fail, since the FD clients will not reconnect and their open 
TCP sockets will timeout. AFAIK, there is no transparent TCP connection 
migration. The virtual IP is migrated, but not the currently opened TCP 
connections. However, this is not necessarily a bad thing. Bacula can be 
configured to automatically re-run failed jobs, and there was some 
reason for the fail-over in the first place. Do we really trust the 
first part of the backup that was made while running on the failing 
cluster node?


I have experimented with running Dir and SD in a KVM VM on a two-node 
Corosync/Pacemaker cluster using active/passive DRBD storage for the 
VM's OS. Backup storage was via iSCSI provided by an existing NAS. I 
found no major issues.


On fail-over, Pacemaker attempts to initiate a shutdown on the failing 
node. If the shutdown succeeds, then the bacula-dir and bacula-sd 
services are stopped in the normal way and it affects running jobs 
exactly the same as if those services were stopped manually. If the 
shutdown fails, then the node is STONITH'd and it is the same effect as 
pulling the power on the node. In that case, the clients' actively 
running jobs are orphaned. Eventually, their TCP sockets timeout. In 
either case, the running jobs are not successful, but as I stated 
earlier, I don't see that as a major reason not to run Bacula in a VM.


Currently, I run Dir and SD in a VM on a four-node cluster, but without 
fail-over for the Bacula VM. The VM and its DRBD storage have to be 
brought up manually, but it allows a single catalog, a single IP, and a 
single set of config, log, and spool files that can be brought up in 
seconds on any one of the nodes. The reason for this is because I do not 
have a FC-attached tape library or other HA capable backup device. To 
bring up on another node I have to move my backup devices (USB-attached 
RDS and portable hard drives plus SATA drives in removable drive bays 
using vchanger). Based on how it worked with iSCS NAS storage, I believe 
it would also work well with HA capable tape hardware on FC (or iSCSI?).


It should also work (ie. jobs running at fail-over will fail, but can be 
automatically re-run) when storing backups on DRBD attached locally to 
the VM. Of course, it doubles the storage space needed for volume files 
and so will be considerable. Since the running jobs will fail at 
fail-over, I see no reason for volume files to be HA. They just need to 
be accessible to the VM, for example on iSCSI-attached NAS.





___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Jari Fredriksson]

Marcio Demetrio Bacci kirjoitti 16.4.2019 5:24:

I have some doubts about Bacula, however I did not find answers on the 
Internet or in the books for the following doubts:


1. Is there any problem in using Bacula virtualized? (I didn't find 
anything saying otherwise)


I run my Bacula server as an LXC container in an CentOS 7 server. No 
problems so far. A dedicated box might be better for some, but this 
works for me.


2. Is there any restriction on mounting the Bacula VM on a DRBD volume 
in the hypervisor. In this VM I will implement ZFS deduplication for my 
backups?


No idea and because of that I'd just try and see. But I see not an 
obvious reason for that to not work.


3. Is there any limitation on the size of Backups with Bacula Community 
version? (I did not find information about any limitations)


No.

4. Having a few jobs with 300 GB or more, though I set up my volumes on 
Bacula with 100 GB, so would you recommend increasing the size of the 
volumes to 200 GB or more?


I use 4.6 GB for my Volumes, and my storage size is a 8 TB Archive Disk 
(SMR). That has a historical reason as once upon a time I stored them to 
DVD-RW. There is this to ponder: when you recycle a Volume, all data in 
the Volume is lost. If you have 200 GB Volumes, you will Lose 200 GB in 
every Volume recycle... To me that matters. The smaller the Volume the 
better.


5. Currently the OS and Backup disks are on the same DRBD volume, so 
would it be better to put the OS disk out of the DRBD volume? (the VM 
has frequently crashing what makes me think that excessive writing on 
the disk may be impacting the OS)


I have no idea about this.

--
Jari Fredriksson
Bitwell Oy
+358 400 779 440
ja...@bitwell.fi
Dev: https://www.bitwell.fi
Ops: https://www.bitwell.biz


--
ja...@iki.fi


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Josip Deanovic]

On Monday 2019-04-15 23:24:10 Marcio Demetrio Bacci wrote:
> I have some doubts about Bacula, however I did not find answers on the
> Internet or in the books for the following doubts:
> 
> 1. Is there any problem in using Bacula virtualized? (I didn't find
> anything saying otherwise)

No.
I have several setups on vmware and kvm. Even few on raspberry-pi and
they are all running for at least 5 years, some of them 10+.

> 2. Is there any restriction on mounting the Bacula VM on a DRBD volume
> in the hypervisor. In this VM I will implement ZFS deduplication for my
> backups?

No. As long as Bacula can use the file system as usual, Bacula will not
be affected by the fact you are using DRBD as it just provides another
block device you are using for your file system of choice (in your case
ZFS).

But you might want to read some articles on the DRBD + ZFS setup if you
haven't done that already.
E.g. http://cedric.dufour.name/blah/IT/ZfsOnTopOfDrbd.html

> 3. Is there any limitation on the size of Backups with Bacula Community
> version? (I did not find information about any limitations)

No. Bacula Systems is kind enough to not impose such limits on Bacula
Community version and it was never a case.

> 4. Having a few jobs with 300 GB or more, though I set up my volumes on
> Bacula with 100 GB, so would you recommend increasing the size of the
> volumes to 200 GB or more?

I prefer to keep them at 10G so that I can maintain them easier in case
I need to deal with the volumes manually.

> 5. Currently the OS and Backup disks are on the same DRBD volume, so
> would it be better to put the OS disk out of the DRBD volume? (the VM
> has frequently crashing what makes me think that excessive writing on
> the disk may be impacting the OS)

Generally, it is good idea to keep OS and the data separated.
That way you can optimize its devices differently performance and
security-wise.

But if your DRBD is the only thing that gives you redundancy then it's
better to keep them both on the DRBD.

However, the crashing VM is really bad problem and is not something
that should be ignored or considered as nuisance.
You should attend to solving this problem before proceeding with
improvements of other systems that rely on that VM and its stability.

Good luck.


Regards!

-- 
Josip Deanovic


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Doubts about Bacula

[Gary R. Schmidt]

On 16/04/2019 12:24, Marcio Demetrio Bacci wrote:
I have some doubts about Bacula, however I did not find answers on the 
Internet or in the books for the following doubts:


1. Is there any problem in using Bacula virtualized? (I didn't find 
anything saying otherwise)


If you mean "running on a VM", then no, there are no problems.  I 
wouldn't do it, but there are reasons I prefer critical infrastructure 
to be stand-alone.


2. Is there any restriction on mounting the Bacula VM on a DRBD volume 
in the hypervisor. In this VM I will implement ZFS deduplication for my 
backups?


I /think/ you are asking if Bacula can handle fail-over during backup?
Short answer is "no".  (I am willing to accept corrections on this, but 
AFAICS Bacula doesn't checkpoint its output.)


3. Is there any limitation on the size of Backups with Bacula Community 
version? (I did not find information about any limitations)


No.  But then I use tape, so limitations are for lusers.

4. Having a few jobs with 300 GB or more, though I set up my volumes on 
Bacula with 100 GB, so would you recommend increasing the size of the 
volumes to 200 GB or more?


I will let someone who uses disk storage answer that.

5. Currently the OS and Backup disks are on the same DRBD volume, so 
would it be better to put the OS disk out of the DRBD volume? (the VM 
has frequently crashing what makes me think that excessive writing on 
the disk may be impacting the OS)



If your VM is crashing, you have really, really bad problems.
Solve them before you put any (more) critical infrastructure on it/them.
Also, see the second half of my answer to your first question.

Cheers,
GaryB-)


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Doubts about Bacula

[Marcio Demetrio Bacci]

I have some doubts about Bacula, however I did not find answers on the
Internet or in the books for the following doubts:

1. Is there any problem in using Bacula virtualized? (I didn't find
anything saying otherwise)
2. Is there any restriction on mounting the Bacula VM on a DRBD volume in
the hypervisor. In this VM I will implement ZFS deduplication for my
backups?
3. Is there any limitation on the size of Backups with Bacula Community
version? (I did not find information about any limitations)
4. Having a few jobs with 300 GB or more, though I set up my volumes on
Bacula with 100 GB, so would you recommend increasing the size of the
volumes to 200 GB or more?
5. Currently the OS and Backup disks are on the same DRBD volume, so would
it be better to put the OS disk out of the DRBD volume? (the VM has
frequently crashing what makes me think that excessive writing on the disk
may be impacting the OS)


Could someone clarify these doubts?

Regards,

Márcio Bacci
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users