> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/documentation/documentation-nl/beveiligen-en-beheren/data-backup-and-recovery.md).
# Back-up en herstel van gegevens
Dispel's aanpak voor gegevensopslag, bewaring en herstel is ontworpen om robuuste beveiliging en operationele veerkracht te bieden. Door gebruik te maken van een combinatie van versleutelde opslagoplossingen, geautomatiseerde back-upmechanismen en geografisch verspreide redundantie, streven we ernaar uw gegevens te beschermen tegen ongeautoriseerde toegang en gegevensverlies. Deze documentatie beschrijft de technische details van hoe deze systemen werken, het beleid dat hierop van toepassing is en de procedures die gevolgd moeten worden in geval van behoefte aan gegevensherstel.
## Gegevenslocaties
Dispel-klanten kunnen kiezen uit een van twee locaties voor gegevensresidentie:
| Dashboardtype | Locatie | Abonnementen |
| ------------- | ---------------- | ------------------- |
| Dispel - VS | Verenigde Staten | SaaS |
| Dispel - EU | Europa | SaaS, Private Cloud |
## Gegevensback-up
Dispel maakt automatische back-ups van alle klant- en systeemgegevens om te beschermen tegen catastrofaal verlies door onvoorziene gebeurtenissen die het hele systeem beïnvloeden. Een geautomatiseerd proces maakt een back-up van alle gegevens naar opslag die bestand is tegen gebeurtenissen die een volledige beschikbaarheidszone beïnvloeden. Standaard wordt er minstens eens per 24 uur een back-up van de gegevens gemaakt. De back-ups worden opgeslagen in een versleuteld gegevensopslagarchief. Back-ups worden gemonitord en er worden meldingen gegenereerd.
Alle databases die door Dispel worden beheerd, bieden continue bescherming door snapshots, basisback-ups en WAL-bestanden naar objectopslag te persisteren. Ook worden fork- en follower-databases geïmplementeerd door snapshots of permanente basisback-ups en WAL-bestanden op te halen en deze af te spelen op een nieuwe Postgres-installatie. Het opslaan van deze fysieke back-ups in een zeer beschikbare objectopslag stelt ons ook in staat om hele databases te herstellen in geval van hardwarestoringen, gegevenscorruptie of een grootschalige serviceonderbreking. Standaard biedt de objectopslag van de subverwerker van Dispel een duurzame infrastructuur om belangrijke gegevens op te slaan en is deze ontworpen voor een duurzaamheid van 99,999999999% van de objecten.
### Soorten back-ups
Dispel maakt volledige databaseback-ups. Transacties die in de database worden vastgelegd, worden geregistreerd als WAL-bestanden, die boven op de snapshots of basisback-ups kunnen worden afgespeeld en zo een methode bieden om de toestand van een database volledig te reconstrueren. Snapshots worden rechtstreeks in objectopslag opgeslagen. Basisback-ups en WAL-bestanden worden via een toepassing genaamd WAL-E naar de objectopslag gepusht zodra Postgres ze beschikbaar stelt.
## Gegevensherstel
Databases kunnen vanuit een koude toestand worden hersteld vanaf back-ups of worden gesynchroniseerd met een bestaande database. Deze staan respectievelijk bekend als *fork* en *volgende* processen. Dispel kan ook terugrollen naar een eerdere databaseback-up.
In alle gevallen wordt een nieuwe database-instantie (N2) aangemaakt, parallel gebracht aan de bestaande database (N1), en vervolgens gepromoveerd tot de primaire database voor de API. Dit wordt gedemonstreerd in het volgende procesdiagram dat een gegevensherstel via een databasefork laat zien:
### Noodherstel / bedrijfscontinuïteit
Ons platform herstelt Postgres-databases automatisch in geval van een storing. Het Dispel-platform is ontworpen om applicaties dynamisch binnen de cloud te implementeren, storingen te monitoren en mislukte platformcomponenten, waaronder klantapplicaties en databases, te herstellen.
## Beperkingen voor bewaartermijnen van back-ups
Productiedatabases draaien op Amazon Aurora (RDS) met geautomatiseerde back-ups die zijn geconfigureerd voor een rollend bewaartermijnvenster van 30 dagen, wat continue point-in-time recovery (PITR) mogelijk maakt tot op elke seconde binnen de meest recente 30 dagen. Geautomatiseerde back-ups omvatten dagelijkse snapshots en transactielogs die in Amazon S3 worden opgeslagen, allemaal versleuteld met KMS en met toegang beperkt tot geautoriseerde operators. Logs kunnen tot een jaar of langer worden bewaard om te voldoen aan vereisten voor compliance, auditing en forensisch onderzoek.
## Gegevensexport / archivering
Klanten kunnen een kopie van hun gegevens aanvragen voor export en archivering. Dispel gebruikt de native `pg_dump` PostgreSQL-tool om zijn back-upbestanden te maken, waardoor export naar andere PostgreSQL-installaties eenvoudig is. Het resulterende back-upbestand gebruikt de optie voor het aangepaste formaat in `pg_dump`. Vergeleken met het platte-tekstformaat kunnen de opties voor het aangepaste formaat resulteren in back-upbestanden die veel kleiner kunnen zijn.
## Gegevenseigendom
Klantgegevens behoren toe aan klanten; Dispel-gegevens behoren toe aan Dispel. Voor meer informatie over hoe Dispel klantgegevens verwerkt, bekijk ons [Privacybeleid](https://legal.dispel.com/policies/privacy-policy).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.dispel.com/documentation/documentation-nl/beveiligen-en-beheren/data-backup-and-recovery.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
