Introduction ============ In a perfect world, there would be no need for a backup. However, it is important, especially in business environments, to be prepared for when the “unexpected” happens. In a database scenario, the unexpected could take any of the following forms: - data corruption - system failure (including hardware failure) - human error - natural disaster In such cases, any ICT manager or DBA should be able to fix the incident and recover the database in the shortest time possible. We normally refer to this discipline as **disaster recovery**, and more broadly *business continuity*. Within business continuity, it is important to familiarise yourself with two fundamental metrics, as defined by Wikipedia: - `**Recovery Point Objective (RPO)** `_ : “maximum targeted period in which data might be lost from an IT service due to a major incident” - `**Recovery Time Objective (RTO)** `_ : “the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity” In a few words, RPO represents the maximum amount of data you can afford to lose, while RTO represents the maximum down-time you can afford for your service. Understandably, we all want **RPO=0** (*“zero data loss”*) and **RTO=0** (*zero down-time*, utopia) - even if it is our grandmothers’s recipe website. In reality, a careful cost analysis phase allows you to determine your business continuity requirements. Fortunately, with an open source stack composed of **Barman** and **PostgreSQL**, you can achieve RPO=0 thanks to synchronous streaming replication. RTO is more the focus of a *High Availability* solution, like `**repmgr** `_ . Therefore, by integrating Barman and repmgr, you can dramatically reduce RTO to nearly zero. Based on our experience at EnterpriseDB, we can confirm that PostgreSQL open source clusters with Barman and repmgr can easily achieve more than 99.99% uptime over a year, if properly configured and monitored. In any case, it is important for us to emphasise more on cultural aspects related to disaster recovery, rather than the actual tools. Tools without human beings are useless. Our mission with Barman is to promote a culture of disaster recovery that: - focuses on backup procedures - focuses even more on recovery procedures - relies on education and training on strong theoretical and practical concepts of PostgreSQL’s crash recovery, backup, Point-In-Time-Recovery, and replication for your team members - promotes testing your backups (only a backup that is tested can be considered to be valid), either manually or automatically (be creative with Barman’s hook scripts!) - fosters regular practice of recovery procedures, by all members of your devops team (yes, developers too, not just system administrators and DBAs) - solicits to regularly scheduled drills and disaster recovery simulations with the team every 3-6 months - relies on continuous monitoring of PostgreSQL and Barman, and that is able to promptly identify any anomalies Moreover, do everything you can to prepare yourself and your team for when the disaster happens (yes, *when*), because when it happens: - It is going to be a Friday evening, most likely right when you are about to leave the office. - It is going to be when you are on holiday (right in the middle of your cruise around the world) and somebody else has to deal with it. - It is certainly going to be stressful. - You will regret not being sure that the last available backup is valid. - Unless you know how long it approximately takes to recover, every second will seem like forever. Be prepared, don’t be scared. In 2011, with these goals in mind, 2ndQuadrant started the development of Barman, now one of the most used backup tools for PostgreSQL. Barman is an acronym for “Backup and Recovery Manager”. Currently, Barman works only on Linux and Unix operating systems.