{"id":1373,"date":"2022-11-26T18:01:08","date_gmt":"2022-11-26T17:01:08","guid":{"rendered":"http:\/\/www.klaushaller.net\/?p=1373"},"modified":"2022-11-26T18:01:08","modified_gmt":"2022-11-26T17:01:08","slug":"backup-basics-on-backup-types-rto-rpo","status":"publish","type":"post","link":"https:\/\/www.klaushaller.net\/?p=1373","title":{"rendered":"Backup Basics: On Backup Types, RTO & RPO"},"content":{"rendered":"\n

Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are essential concepts for business-critical applications. The RTO defines the maximum time an application might be unavailable after a crash \u2013 or after a data center burns down (Figure 1). That is the time engineers (or automatic processes) have to start the application on other servers – potentially at a different location \u2013 and restore all necessary data from backups.<\/p>\n\n\n\n

\"\"<\/a>
Figure 1: Understanding RPO, RTO, and Backup Frequencies<\/figcaption><\/figure>\n\n\n\n

How much data might get lost max in such an event, this defines the RPO, the Recovery Point Objective<\/strong>. It depends on the backup frequency. If a company makes a backup each night at 4 am, the RPO is 24 hours. Then, if the data center burns down at 4:15, only the data from the last 15 minutes is lost. If it burns down at 3 am, the data from 23 hours is lost.<\/p>\n\n\n\n

One factor influencing the RTO is the time needed to restore the data from a backup. Network bandwidth and storage are significant factors, but so is the backup type. Full, incremental, and differential backups take different long.<\/p>\n\n\n\n

The starting point is always a full backup<\/strong>. The system writes all data to a secure backup storage (Figure 2). So, why would an architect not always go for a full backup? It is simple: Suppose an application is highly critical. Thus, the RPO is 5 min. Let us further assume that it is a massive database, but not much data changes within five minutes. Then, a full backup every five minutes seems too much. It might even be technically impossible, depending on network bandwidth and the amount of data. Incremental backups can be a better solution for such a scenario.<\/p>\n\n\n\n

\"\"<\/a>
Figure 2: Understanding Full, Incremental, and Differential Backups<\/figcaption><\/figure>\n\n\n\n

An incremental backup<\/strong> copies only the most recent changes away. If the last full backup was at 4 am, an incremental backup at 4:05 am copies the changes from the last five minutes. The next backup at 4:10 am copies, as well, only the changes of the last five minutes, i.e., the changes between 4:05 am and 4:10 am. Incremental backups have on disadvantage compared to full backups: the restoration time might be longer. To restore the situation of 4:10 am, one has to fully restore the data from 4 am, then apply what changed till 4.05 am, and then the incremental changes till 4:10 am.<\/p>\n\n\n\n

A middle way between incremental and full backups is the differential backup<\/strong>. A differential backup copies away all changes from the last full backup. At 4:05 am, a differential backup writes all changes of the last five minutes; at 4:10 am, all changes between 4:00 and 4:10, and at 4:15, all changes between 4:00 and 4:15. Thus, a restore of an incremental backup means: restore the full backup and (only) apply the changes of the last differential backup. However, these concepts get transparent with the cloud: the cloud providers implement standard configurations.<\/p>\n\n\n\n

The Azure Backup Center, for example, enables customers to configure several backups per day for VMs based on the Service Recovery Vaults, e.g., every 4 hours. The first one is a full backup; the subsequent backups are incremental (Figure 3). Microsoft has decided. However, these concepts are still crucial for architects and engineers if they implement their own solutions or use 3rd<\/sup> party software with sophisticated configuration features. Then, they have to optimize and experiment themselves to identify an appropriate balance between \u2026<\/p>\n\n\n\n