Fiecare data store din AWS are backup-uri pornite implicit sau printr-o bifă. Aurora păstrează backup-uri automate. DynamoDB are point-in-time recovery. S3 are versionare. Consola arată bife verzi, chestionarul de conformitate primește un „da” și nimeni n-a restaurat vreodată nimic, deci nimeni nu știe cât durează o restaurare, dacă merge sau ce se strică când copia restaurată are alt nume.
Noi facem un exercițiu de restaurare în fiecare trimestru, într-un cont separat, cu cronometrul. Ăsta e exercițiul din trimestrul trecut: ce am restaurat, cât a durat fiecare pas, cele patru lucruri care au picat și ce spun cifrele despre obiectivele noastre reale de recuperare, spre deosebire de cele de pe slide.
Ce e salvat și cum
Starea platformei trăiește în trei locuri: un cluster Aurora Serverless v2, șase tabele DynamoDB și două bucket-uri S3. Backup-urile, toate definite în CDK:
| Store | Mecanism | Retenție | Unde trăiește copia |
|---|---|---|---|
| Aurora | Backup continuu automat, point-in-time | 35 de zile | Același cont, plus un snapshot zilnic copiat în contul de backup prin AWS Backup |
| DynamoDB | Point-in-time recovery, continuu | 35 de zile | Același cont, plus AWS Backup zilnic într-un vault în alt cont |
| S3 | Versionare + lifecycle | Versiunile vechi păstrate 90 de zile | Același bucket, plus replicare în contul de backup |
| Secrete, parametri | AWS Backup nu le acoperă | n/a | Reconstruite din definițiile CDK și un checklist |
Copia în alt cont e partea pe care o sare lumea. Un backup în același cont cu producția protejează de o migrare proastă sau de o ștergere din greșeală. Nu protejează de compromiterea contului în sine, sau de un cdk destroy cu contextul greșit care șterge lucruri cu RETAIN oprit. AWS Backup cu un vault într-un cont separat, cu vault lock, e ce face copia să supraviețuiască celei mai proaste zile. Costă cam $6 pe lună la dimensiunea noastră.
Exercițiul, cu cronometrul
Scenariul: datele de producție de la ora 14:00 ieri sunt corupte; restaurezi totul la 13:55 și aduci aplicația sus pe datele restaurate. În staging, din contul de backup, cu suita de smoke test ca definiție pentru „sus”. Un inginer, fără ajutor, urmând runbook-ul.
| Pas | Timp | Note |
|---|---|---|
| Aurora: restaurare cluster la un moment în timp din copia din vault | 22 min | Cluster nou, endpoint nou. Serverless v2, 0,5 ACU |
| Aurora: query de smoke, verificare număr de rânduri față de dashboard-ul de metrici | 3 min | S-au potrivit |
| DynamoDB: restaurare a șase tabele din vault, în paralel | 31 min | Cea mai mare tabelă, 18 GB, a luat 28 din ele |
| DynamoDB: reactivare PITR și TTL pe tabelele restaurate | 4 min | Restaurarea nu le păstrează. Nici auto-scaling-ul, tag-urile sau stream-ul |
| S3: nimic de restaurat pentru scenariul ăsta; doar verificarea versionării | 2 min | |
| Reîndreptarea aplicației: scrierea noului endpoint de cluster și a numelor de tabele în SSM | 5 min | Ar fi trebuit să fie un minut; vezi eșecul 3 |
| Repornirea serviciilor App Runner și a Lambda-urilor ca să citească noii parametri | 6 min | |
| Smoke test-uri verzi | 4 min | |
| Total | 77 min |
Șaptezeci și șapte de minute pentru o restaurare completă la un moment în timp, de o singură persoană care urmează instrucțiuni. Ăsta e obiectivul real de timp de recuperare, și e numărul care intră în runbook, nu „sub o oră” care era pe slide înainte de primul exercițiu.
Cele patru lucruri care au picat
Primul exercițiu, acum un an, a durat patru ore și nu s-a terminat. Fiecare trimestru de atunci a găsit ceva. Cele patru din trimestrul trecut:
1. Politica cheii KMS nu permitea contului de staging să decripteze snapshot-ul Aurora. Copia din vault e criptată cu o cheie din contul de backup. Restaurarea în staging are nevoie ca politica acelei chei să acorde kms:Decrypt și kms:CreateGrant rolului de restaurare din staging. Le acorda celui din producție. Restaurarea a picat cu o eroare de permisiuni care a luat douăzeci de minute de citit corect. Rezolvat în CDK: politica cheii listează acum fiecare cont care ar putea restaura.
2. Restaurarea DynamoDB pierde setările tabelei. O tabelă restaurată are datele și schema de chei și nimic altceva: fără PITR, fără atribut TTL, fără auto-scaling, fără tag-uri, fără stream. Aplicația noastră se bazează pe TTL ca să expire sesiunile și pe stream ca să alimenteze indexul de căutare. Fără un pas de checklist pentru reactivarea lor, aplicația restaurată „mergea” și încetase în liniște să expire sesiunile. E acum un pas în runbook și, mai bine, un script mic care aplică setările din definiția CDK pe o tabelă numită.
3. O Lambda avea numele tabelei hard-codat. Unsprezece din douăsprezece funcții își citesc numele tabelelor din parametri SSM, deci reîndreptarea era o scriere de parametru. Una, cea mai veche, avea numele tabelei de producție ca literal în mediu. A continuat fericită să scrie în tabela veche în timpul exercițiului, ceea ce într-o recuperare reală ar fi însemnat scrierea de date noi în store-ul corupt. Găsită pentru că smoke test-ul pentru funcția aia a picat. Rezolvată prin mutarea numelui în SSM ca la celelalte, și printr-o verificare în CI care caută în blocurile de mediu orice se potrivește cu un pattern de nume de resursă.
4. Rolul de restaurare din staging nu putea face PassRole către rolul de serviciu Aurora. O omisiune IAM de o linie, descoperită la minutul 30, rezolvată la minutul 35, și un memento că drumul de restaurare are propriul set de permisiuni pe care nimic nu-l exersează în afară de exercițiu.
Niciuna dintre astea n-ar fi fost găsită uitându-ne la bifele verzi. Toate patru ar fi transformat un incident real din „o după-amiază proastă” în „o săptămână proastă”.
Cifrele care au ieșit din el
Obiectivul de punct de recuperare: cinci minute pentru Aurora și DynamoDB, pentru că point-in-time recovery e continuu; S3 e imediat prin versionare. Partea asta era adevărată și înainte de exercițiu.
Obiectivul de timp de recuperare: 77 de minute pentru o restaurare completă, cam 30 pentru o singură tabelă DynamoDB, cam 25 pentru Aurora singură. Numerele alea erau ficțiune înainte de exercițiu și sunt măsurători acum. Sunt în runbook și în template-ul paginii de status, deci mesajul în timpul unei recuperări reale zice „restaurare în curs, finalizare estimată la 15:20”, nu „în curând”.
Costul exercițiului: cam $4 în resurse restaurate pentru o după-amiază, plus după-amiaza unui inginer. Costul de a nu-l face: necunoscut până în ziua în care contează, care e ziua greșită pentru a învăța.
Runbook-ul, condensat
- Declari momentul țintă în timp. Îl scrii înainte să atingi ceva.
- Restaurezi în contul izolat. Niciodată peste producție; restaurezi lângă ea și reîndrepți.
- Aurora: restaurare la un moment în timp din copia din vault; verifici numărul de rânduri față de o metrică cunoscută.
- DynamoDB: restaurezi toate tabelele în paralel; apoi rulezi scriptul de setări pentru PITR, TTL, stream-uri, auto-scaling, tag-uri.
- S3: identifici versiunile obiectelor la momentul țintă; copiezi înainte dacă e nevoie.
- Reîndreptare: aplicația citește fiecare nume de resursă din SSM. Scrii numele noi. Nimic nu e hard-codat, iar CI impune asta.
- Repornești tot ce cache-uiește parametri.
- Smoke test-uri. Nu „se încarcă”: suita care exersează checkout-ul, login-ul și indexul de căutare.
- Cronometrezi fiecare pas. Actualizezi RTO-ul din runbook dacă s-a mișcat.
- Dărâmi și scrii nota de o pagină cu ce a picat.
Trimestrial. În calendar. Cu alt inginer de fiecare dată, pentru că rostul e ca runbook-ul să funcționeze pentru persoana care nu l-a scris.
Dacă backup-urile tale au bife verzi și niciun istoric de restaurare, facem primul exercițiu împreună. Bugetează o după-amiază și așteaptă-te să găsești ceva.