Zo berekent u onveranderbare back-upopslag, overdrachtstijd en cloud-egresskosten voor een offsite kopie

Budgetaanvragen voor een offsite back-up gaan meestal op een van twee manieren mis: de opslag wordt berekend als ‘één kopie van de schijven’, of de rekening voor cloud-egress wordt vergeten. Beide fouten komen pas maanden later aan het licht — als de retentie de bucket heeft gevuld of de eerste factuur binnenkomt.

In deze gids vindt u de formules waarmee wij een onveranderbare offsite kopie dimensioneren — opslag, overdrachtstijd, egress en herstelcapaciteit — met een rekenvoorbeeld dat u op uw eigen cijfers kunt toepassen.

De vijf gegevens die u nodig hebt

1. Gebruikte data (D) — de data die werkelijk op de beschermde schijven staat, niet hun toegewezen omvang. Een schijf van 4 TB die voor 40% gevuld is, telt mee voor 1,6 TB.
2. Datareductiefactor (r) — de compressie en deduplicatie die de back-upsoftware realiseert; 1,3–2× is gebruikelijk voor gemengde servers.
3. Dagelijkse wijziging (Δ) — nieuwe en gewijzigde blokken per dag, na reductie. Meet deze aan de hand van de incrementele groottes van uw huidige back-ups.
4. Bewaarbeleid — hoeveel dagelijkse, wekelijkse en maandelijkse herstelpunten u bewaart.
5. Groei — de verwachte datagroei over de contractperiode, doorgaans 10–20% per jaar.

Opslagformule voor GFS-retentie

Bij incremental-forever-back-ups op objectopslag bewaart elk herstelpunt alleen de blokken die zijn gewijzigd en die niet worden gedeeld met nieuwere punten. Dat levert een eenvoudige schatting op:

Opslag ≈ F + Nd × Δ + Nw × Δw + Nm × Δm + overhead

F   = D / r        volledige kopie
Nd  = dagelijkse punten          Δ  = dagelijkse wijziging
Nw  = extra wekelijkse punten    Δw ≈ 2,5 × Δ
Nm  = extra maandelijkse punten  Δm ≈ 6 × Δ
overhead ≈ 10% voor Object Lock en metadata

De factoren voor wekelijkse en maandelijkse punten weerspiegelen dat veel dagelijkse wijzigingen dezelfde blokken overschrijven; vervang ze door gemeten waarden zodra u een maand historie hebt. Rekenvoorbeeld: 20 TB gebruikte data, 1,5× reductie en 200 GB dagelijkse wijziging.

Het bewaarbeleid verdubbelt de benodigde capaciteit grofweg. Leg het per systeem vast: systemen in categorie I hebben vaak 12 maandelijkse punten nodig, terwijl test- en ondersteunende systemen met 14 dagen toekunnen.

Object Lock en overhead voor onveranderbaarheid

Object Lock in compliancemodus bewaart elk object tot de bewaardatum, ook als de back-upsoftware het niet meer nodig heeft. Back-uptools verlengen lockperiodes daarom in blokken van dagen (Veeam telt er bijvoorbeeld doorgaans tot tien dagen bij op), en verlopen punten worden pas verwijderd als de lock is afgelopen. Reken op 10–15% bovenop de retentieberekening en plan onveranderbare opslag nooit op 100% bezetting: een volle bucket kunt u niet voortijdig opschonen.

Initiële seeding: bandbreedte en doorlooptijd

De eerste volledige kopie is de grootste overdracht. Dimensioneer de verbinding zo dat de seeding binnen twee weken klaar is, en houd er rekening mee dat over langere periodes slechts ongeveer 80% van de nominale bandbreedte bruikbaar is:

Dagen = Data (TB) × 8.000.000 / (Bandbreedte (Mbit/s) × 0,8 × 86.400)

Dagelijkse incrementele back-ups zijn veel kleiner: 500 GB in een venster van acht uur vraagt ongeveer 140 Mbit/s, of minder dan 50 Mbit/s als u de overdracht over 24 uur spreidt.

Egresskosten in de cloud

Data die een publieke cloud verlaat (egress), wordt per gigabyte gefactureerd door de cloudprovider, niet door de back-upprovider; daarom hoort deze post apart in de budgetaanvraag. Azure-lijstprijzen voor internet-egress vanuit Europa (gerouteerd via het Microsoft-netwerk):

In het rekenvoorbeeld kost de seeding van de volledige kopie van 13,3 TB ongeveer $ 1.137, en 6 TB aan maandelijkse wijzigingen circa $ 513 per maand, oftewel $ 6.160 per jaar. Drie hefbomen verlagen de rekening: compressie en deduplicatie vóór de overdracht, de goedkopere optie ‘routeringsvoorkeur: internet’ ($ 0,08 en $ 0,065 per GB in de eerste twee staffels) en sponsor- of creditprogramma’s die het abonnement mogelijk al dekken.

Herstelcapaciteit dimensioneren

Hersteltests vragen rekenkracht en schijfruimte naast de back-upopslag. Dimensioneer de pool op het grootste systeem dat u in één keer moet terugzetten, niet op een gemiddeld systeem:

• Schijfruimte: de gebruikte data van het grootste systeem plus 20% werkruimte.
• Rekenkracht: genoeg vCPU en RAM om de servers van dat systeem tegelijk te draaien — bijvoorbeeld twee VM’s met elk 8 vCPU en 32 GB.
• Tijd: alle systemen testen kost doorgaans twee tot vier weken pooltijd per jaar.

Checklist voor dimensionering

• Meet de gebruikte data per server en de omvang van databases, niet de toegewezen schijven.
• Haal 30 dagen aan incrementele groottes uit uw huidige back-ups om de werkelijke dagelijkse wijziging te bepalen.
• Spreek de bewaartermijn per systeemcategorie af voordat u prijzen opvraagt.
• Tel er 10–15% bij op voor onveranderbaarheid en 10–20% voor groei.
• Dimensioneer de verbinding voor de seeding op 14 dagen of minder, en het dagelijkse venster op de piek in de wijzigingen.
• Neem cloud-egress als aparte post op in de budgetaanvraag.

Liever niet zelf rekenen? Stuur ons de gegevens: wij dimensioneren de soevereine offsite back-upreserve en leveren een architectuur met kostenraming.