On Tue, Apr 23, 2019 at 3:57 PM Josh Fisher <jfis...@pvct.com> 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
