Cum dimensionați stocarea pentru backup imuabil, timpul de transfer și costurile de egress din cloud pentru o copie offsite

Solicitările de buget pentru un backup offsite greșesc de obicei în unul din două moduri: stocarea este dimensionată ca „o copie a discurilor” sau factura pentru traficul de ieșire din cloud (egress) este omisă. Ambele greșeli ies la iveală abia după câteva luni — când retenția umple spațiul de stocare sau când sosește prima factură.

Acest ghid prezintă formulele pe care le folosim pentru dimensionarea unei copii offsite imuabile — stocare, timp de transfer, egress și capacitate de restaurare — împreună cu un exemplu de calcul pe care îl puteți adapta la propriile cifre.

Cei cinci parametri de care aveți nevoie

1. Datele utilizate (D) — datele stocate efectiv pe discurile protejate, nu capacitatea alocată a acestora. Un disc de 4 TB ocupat în proporție de 40% contribuie cu 1,6 TB.
2. Raportul de reducere a datelor (r) — compresia și deduplicarea obținute de software-ul de backup; pentru servere mixte, valorile tipice sunt de 1,3–2×.
3. Modificarea zilnică (Δ) — blocurile noi și modificate pe zi, după reducere. Măsurați-o pe baza dimensiunilor backup-urilor incrementale actuale.
4. Politica de retenție — câte puncte de restaurare zilnice, săptămânale și lunare păstrați.
5. Creșterea — creșterea estimată a volumului de date pe durata contractului, de obicei 10–20% pe an.

Formula de calcul a stocării pentru retenția GFS

În cazul backup-urilor incrementale permanente (incremental-forever) pe stocare de obiecte, fiecare punct de restaurare conține doar blocurile care s-au modificat și nu sunt partajate cu punctele mai noi. Rezultă o estimare simplă:

Stocare ≈ F + Nd × Δ + Nw × Δw + Nm × Δm + supliment

F   = D / r        copie completă
Nd  = puncte zilnice                   Δ  = modificare zilnică
Nw  = puncte săptămânale suplimentare  Δw ≈ 2,5 × Δ
Nm  = puncte lunare suplimentare       Δm ≈ 6 × Δ
supliment ≈ 10% pentru Object Lock și metadate

Multiplicatorii pentru punctele săptămânale și lunare reflectă faptul că multe modificări zilnice suprascriu aceleași blocuri; înlocuiți-i cu valori măsurate după ce aveți un istoric de o lună. Exemplu de calcul: 20 TB de date utilizate, reducere de 1,5× și 200 GB de modificări zilnice.

Politica de retenție aproape dublează capacitatea necesară. Stabiliți-o pentru fiecare sistem în parte: sistemele de categoria I au adesea nevoie de 12 puncte lunare, în timp ce pentru sistemele de test și cele auxiliare sunt suficiente 14 zile.

Object Lock și spațiul suplimentar pentru imuabilitate

Object Lock în modul compliance păstrează fiecare obiect până la data de expirare a retenției, chiar și după ce software-ul de backup nu mai are nevoie de el. De aceea, instrumentele de backup prelungesc perioadele de blocare în tranșe de câteva zile (Veeam, de exemplu, adaugă de regulă până la zece zile), iar punctele expirate sunt eliminate abia după încetarea blocării. Prevedeți în buget 10–15% peste necesarul calculat pentru retenție și nu planificați niciodată o utilizare de 100% a stocării imuabile: un bucket plin nu poate fi curățat înainte de termen.

Transferul inițial: lățime de bandă și durată

Prima copie completă reprezintă cel mai mare transfer. Planificați canalul astfel încât transferul inițial să se încheie în cel mult două săptămâni, ținând cont că, pe perioade lungi, se poate folosi efectiv doar circa 80% din lățimea de bandă nominală:

Zile = Date (TB) × 8.000.000 / (Lățime de bandă (Mbit/s) × 0,8 × 86.400)

Backup-urile incrementale zilnice sunt mult mai mici: 500 GB într-o fereastră de opt ore necesită circa 140 Mbit/s, iar dacă transferul este distribuit pe 24 de ore, ajung mai puțin de 50 Mbit/s.

Costurile de egress din cloud

Datele care ies dintr-un cloud public sunt facturate per gigabyte de furnizorul de cloud, nu de furnizorul de backup, așa că trebuie incluse în solicitarea de buget ca linie separată. Prețurile de listă Azure pentru traficul de ieșire către internet din Europa (rutat prin rețeaua Microsoft):

În exemplul de calcul, transferul inițial al copiei complete de 13,3 TB costă circa 1.137 USD, iar 6 TB de modificări lunare, circa 513 USD pe lună, adică 6.160 USD pe an. Trei pârghii reduc factura: compresia și deduplicarea înainte de transfer, opțiunea mai ieftină „routing preference: internet” (0,08 USD și 0,065 USD per GB în primele două trepte) și programele de sponsorizare sau de credite care pot acoperi deja abonamentul.

Dimensionarea capacității de restaurare

Testele de restaurare au nevoie de resurse de calcul și de spațiu pe disc în apropierea stocării de backup. Dimensionați pool-ul pentru cel mai mare sistem pe care trebuie să îl restaurați dintr-odată, nu pentru unul mediu:

• Disc: datele utilizate ale celui mai mare sistem, plus 20% spațiu de lucru.
• Resurse de calcul: suficiente vCPU și RAM pentru a rula simultan serverele acestuia — de exemplu, două mașini virtuale, fiecare cu 8 vCPU și 32 GB.
• Timp: testarea tuturor sistemelor necesită de obicei între două și patru săptămâni de utilizare a pool-ului pe an.

Lista de verificare pentru dimensionare

• Măsurați datele utilizate pe fiecare server și dimensiunea bazelor de date, nu capacitatea alocată a discurilor.
• Extrageți dimensiunile backup-urilor incrementale din ultimele 30 de zile pentru a afla modificarea zilnică reală.
• Stabiliți retenția pe categorii de sisteme înainte de a solicita oferte de preț.
• Adăugați 10–15% pentru imuabilitate și 10–20% pentru creștere.
• Dimensionați canalul pentru un transfer inițial de cel mult 14 zile, iar fereastra zilnică pentru rata maximă de modificare.
• Includeți costurile de egress din cloud în solicitarea de buget, ca linie separată.

Preferați să nu faceți singuri calculele? Trimiteți-ne datele de intrare: dimensionăm rezerva de backup offsite suverană și vă trimitem o arhitectură însoțită de estimarea costurilor.