Hello, pt., 19 kwi 2019 o 13:28 Heitor Faria <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? 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 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. When you implement a Disaster Recovery solution then in most cases it is designed as a one-way failover which requires a careful preparation to make a next failover. Why, you may ask? It is because designing Disaster Recovery solution which can do any direction failover will cost a lot of cash and it is simply cheaper to make on-way solution. A surprising large amount of my customers wants Bacula HA but do not want > to use clusters or 3rd party solutions. > Well, all of my customers wants DR solution and some of them wants both HA + DR solutions. DR solutions focus on procedures how to avoid any data loss. HA solutions focus on procedures how to maintain service in running state. There is no native Bacula HA solution. You have to always use a third party components. There is a native DR solution in Bacula - asynchronous backup jobs replication. 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
