Tanquem la Part VI amb el Capítol 26: Alta disponibilitat i disaster recovery, que tracta sobre com aconseguir que els teus sistemes resisteixin fallades i desastres. Perquè les coses fallen: un servidor cau, una regió té problemes, algú esborra dades per error. La pregunta no és si fallarà alguna cosa, sinó quan, i com de preparat estàs. Abans de veure estratègies i eines, necessitem dos conceptes fonamentals que guien totes les decisions de recuperació: RTO i RPO.

Una veritat incòmoda dels sistemes: tot falla en algun moment. Discos, servidors, xarxes, fins i tot centres de dades sencers. Les empreses serioses no fan veure que no passarà; es preparen per quan passi. Aquesta preparació per recuperar-se de fallades greus s’anomena disaster recovery (recuperació davant desastres, DR).

Però «estar preparat» costa diners i esforç, i no totes les aplicacions necessiten el mateix nivell. Quant has d’invertir en recuperació? Per respondre, primer cal definir quin nivell de recuperació necessites, i això es mesura amb dues preguntes: RTO i RPO.

RTO (Recovery Time Objective) és el temps màxim que el teu sistema pot estar caigut després d’un desastre abans de recuperar-se. Respon a la pregunta: «si això cau, en quant temps necessito que torni a funcionar?»

Exemples d’RTO segons el tipus de sistema:

• Una botiga online en plena campanya: RTO de minuts (cada minut caigut = vendes perdudes).
• Una eina interna d’informes: RTO de hores (molest, però tolerable).
• Un sistema d’arxiu històric: RTO de dies (gairebé ningú ho nota).

Analogia: l’RTO és com preguntar-te, si se t’espatlla el cotxe, «quant temps puc estar sense cotxe?». Si el necessites per treballar cada dia, vols que estigui arreglat en hores (RTO baix), encara que això signifiqui pagar una grua urgent i un taller exprés. Si és un cotxe de cap de setmana, pots esperar una setmana sense problema (RTO alt) i buscar la reparació més barata.

RPO (Recovery Point Objective) és la quantitat màxima de dades (mesurada en temps) que et pots permetre perdre en un desastre. Respon a: «si això cau, fins a quin moment en el passat necessito recuperar les dades sense que sigui un problema?». A la pràctica, marca cada quant necessites fer còpies de seguretat.

Si la teva última còpia va ser fa 1 hora i ocorre un desastre, perds l’última hora de dades. Exemples:

• Un banc: RPO de segons (no pot perdre ni una transacció).
• Una botiga online: RPO de minuts (perdre uns minuts de comandes seria greu però no catastròfic).
• Un blog: RPO de hores o un dia (perdre els últims comentaris és tolerable).

Analogia: l’RPO és com preguntar-te «quanta feina puc permetre’m perdre si s’apaga l’ordinador sense desar?». Si deses cada 5 minuts, com a molt perds 5 minuts de feina (RPO de 5 min). Si només deses un cop al dia, podries perdre un dia sencer de feina. Com menys et puguis permetre perdre, més sovint has de desar (còpies més freqüents).

És fonamental no confondre’ls: mesuren coses diferents.

RTO i RPO són la brúixola de tot el teu pla de recuperació. Com més exigents siguin (RTO i RPO de minuts o segons), més costa la solució (necessites sistemes duplicats, còpies constants, automatització...). Com més relaxats, més barat.

Per això, el primer pas sempre és preguntar al negoci: «quant temps de caiguda i quantes dades podem tolerar?». La resposta determina quant invertir. No té sentit gastar una fortuna en recuperació instantània per a un sistema que ningú trobaria a faltar durant un dia.

Exemple del món real: una empresa defineix RTO i RPO per a cada sistema. Per a la seva plataforma de pagaments: RTO de 5 minuts i RPO de 0 (no poden perdre cap transacció ni estar caiguts), així que inverteixen en una arquitectura duplicada i costosa. Per al seu sistema intern d’informes: RTO de 8 hores i RPO de 24 hores, així que una simple còpia diària i una recuperació manual són suficients, estalviant molts diners. Mateixa empresa, estratègies molt diferents, cadascuna ajustada al que cada sistema realment necessita. Definir RTO i RPO primer els permet invertir els diners on realment importa.

• Tot falla en algun moment; les empreses serioses es preparen per recuperar-se (disaster recovery). Però «estar preparat» costa, i cada sistema necessita un nivell diferent.
• RTO (Recovery Time Objective): el temps màxim de caiguda tolerable abans de recuperar-se («en quant torno?»). Mira al futur; afecta la velocitat de recuperació.
• RPO (Recovery Point Objective): la quantitat màxima de dades (en temps) que pots perdre («quantes dades perdo?»). Mira al passat; marca la freqüència de les còpies.
• No es confonen: RPO mira al passat (dades perdudes), RTO mira al futur (temps de tornada).
• Com més exigents (minuts/segons), més cara la solució. Per això el primer pas és preguntar al negoci què pot tolerar, i invertir en conseqüència.

En el següent subcapítol veurem les diferents estratègies de disaster recovery (de la més barata a la més ràpida) que tries segons el teu RTO i RPO.