Websites
Point-in-Time Recovery
Point-in-time recovery lets you rebuild your database as it was at a chosen minute, rather than only at the moment yesterday's backup ran. This guide covers what it does and does not cover, how to…
Point-in-time recovery laat je je database herbouwen zoals deze was op een gekozen moment, in plaats van alleen op het moment waarop gisteren's backup werd uitgevoerd. Deze gids behandelt wat het wel en niet dekt, hoe je het inschakelt, hoe je een restore aanvraagt, en precies wat een restore raakt.
Waarvoor het is
Een dagelijkse backup geeft je één herstelpunt per dag. Dat is prima voor de meeste rampen en nutteloos voor de specifieke ramp waarbij een slechte import, een defecte plugin, of een foute bulk-edit om 14:15 uur werd uitgevoerd en je het om 16:00 uur opmerkte. Het herstellen van gisteren's backup zou al het echte werk van de ochtend samen met de fout weggooien.
Point-in-time recovery sluit deze kloof. Met dit ingeschakeld, wordt het wijzigingenlogboek van de database continu naar offsite-opslag verzonden, zodat een restore kan worden afgespeeld tot elk moment binnen het bewaarde venster.
Point-in-time recovery dekt ALLEEN de DATABASE. Het dekt je bestanden niet: geen uploads, geen theme- of plugincode, geen configuratiebestanden op schijf. Als iemand een map met afbeeldingen heeft verwijderd, zal PITR deze niet terugbrengen. Voor bestanden heb je een bestandsback-up nodig. Zie Een backup maken en Herstellen uit een backup.
Waar het in KPanel te vinden is
- Meld je aan bij KPanel.
- Klik op Websites in de linker zijbalk en klik vervolgens op de site.
- Open in de tabstrip van de site Backups en vervolgens Point-in-time recovery.
Het directe adres is /websites/<site-id>/pitr.
Geschiktheid
Point-in-time recovery vereist twee dingen.
Je plan moet het bevatten. Het is beschikbaar op de WordPress-plantaamlies.
De site moet een WordPress- of WooCommerce-site zijn, omdat het mechanisme afhankelijk is van een beheerde database.
Als een van beide niet waar is, staat op de pagina duidelijk: point-in-time recovery is alleen beschikbaar voor WordPress- en WooCommerce-sites met beheerde databases. Er is in dat geval niets in te stellen.
Het inschakelen
De PITR-status kaart toont de huidige staat met een statuspictogram, de gebruikte backend, wanneer het laatste wijzigingenlogboek werd verzonden, en het bewaringvenster in dagen.
Klik op Enable PITR om het in te schakelen. De bewaring bedraagt 30 dagen.
Het inschakelen verandert niets aan je gegevens. Het start een continu verzendproces dat naast je normale dagelijkse backups loopt; het vervangt ze niet.
Er zijn onmiddellijk na het inschakelen geen herstelpunten. De verzending moet minstens één keer worden uitgevoerd voordat iets kan worden afgespeeld, en de eerste verzending vindt plaats binnen ongeveer vijf minuten. Tot die tijd vertelt de pagina je dat er nog geen herstelpunten zijn.
Het herstelvenster lezen
Zodra de verzending actief is, geeft de kaart Available restore window de vroegste en laatste momenten aan waarnaar je kunt herstellen, en hoeveel wijzigingenlogboekbestanden worden bewaard om dit te dekken.
Lees dit voordat je het nodig hebt, niet tijdens een incident. Als het venster later begint dan je verwachtte, is de verzending op een bepaald moment onderbroken en is oudere dekking verlopen.
Een restore aanvragen
- Open het tabblad Point-in-time recovery.
- Bevestig dat het herstelvenster het moment dat je wilt dekt.
- In Restore to timestamp kies je de datum en het moment. Kies een moment net VOOR de schade, niet erna.
- Klik op Request restore to staging DB.
De aanvraag wordt meteen gevalideerd. Als de timestamp buiten het beschikbare venster valt, krijg je het exacte venster te zien in plaats van te moeten gokken.
Wat een restore eigenlijk doet
Dit is het onderdeel om precies over te zijn, omdat het het tegenovergestelde is van wat de meeste mensen verwachten.
Een point-in-time restore raakt je live database niet. Het herstelt in een aparte staging database, die voor dit doel wordt aangemaakt en genoemd naar je domein en de doeldatum. Je live site blijft gedurende de gehele periode op zijn eigen database draaien, ongewijzigd.
Niets wordt overschreven, niets wordt verwijderd, en er gaan geen gegevens verloren door een restore aan te vragen. Dit is opzettelijk: het hele doel van een gegevensherstelgereedschap is dat het gebruik ervan de situatie niet erger kan maken.
Wat je krijgt is een database die je kunt inspecteren. Je kunt deze vergelijken met de live database, de beschadigde rijen eruit trekken, of beslissen dat de volledige snapshot de versie is die je wilt. Het promoveren van een staging restore naar je live database is een aparte, opzettelijke stap die ons team met je doet, niet iets dat een knop achter de schermen doet.
Overschakelen naar een herstelde database GOOIT alles weg wat na het herstelpunt naar de live database is geschreven. Orders geplaatst, opmerkingen achtergelaten, en inhoud bewerkt na die timestamp bestaan alleen in de live database. Voordat je overschakelt, bepaal je wat moet worden doorgegeven en zeg je dit. Dit is de reden waarom de restore eerst in staging terechtkomt.
De aanvraag volgen
Elke aanvraag verschijnt in de tabel Restore requests:
| Kolom | Wat het toont |
|---|---|
| Requested | Wanneer je erom vroeg |
| Target | De timestamp waarnaar je wilt herstellen |
| Status | Waar de aanvraag is gekomen |
| Staging DB | De naam van de database waarnaar wordt hersteld |
Terwijl een restore wordt uitgevoerd, toont de status de huidige fase en, zodra het afspelen begint, hoeveel wijzigingenlogboekbestanden zijn toegepast uit het totaal. Een mislukte aanvraag toont de fout eronder.
Slechts één restore kan tegelijk per site actief zijn. Het aanvragen van een tweede terwijl één actief is, retourneert een conflict in plaats van in de wachtrij te plaatsen, zodat een tweede poging de eerste niet kan beschadigen.
Ons engineeringteam voltooit de staging restore en stuurt je een e-mail wanneer de staging database klaar is. Je krijgt ook een bevestigings-e-mail wanneer de aanvraag wordt ontvangen, met de doeltimestamp en de naam van de staging database.
Het juiste moment kiezen
Bepaal wanneer de schade begon, niet wanneer je het opmerkte. Dit zijn meestal uren uit elkaar. Controleer je activiteitenlogboek, je ordertijdstempels, of je laatste bekende juiste content edit.
Richt een minuut of twee eerder. Een herstelpunt net voor de slechte gebeurtenis kost je een paar minuten rechtmatige schrijfbewerkingen. Eén na afloop herstelt de schade samen met alles wat er verder is.
Noteer wat na het herstelpunt is gebeurd. Orders, inschrijvingen, opmerkingen, formulierinzendingen. Die lijst is wat je handmatig moet meenemen als je overschakelt.
Probleemoplossing
Op de pagina staat dat PITR alleen beschikbaar is voor WordPress en WooCommerce. De site is niet een van die typen, of je plan bevat de functie niet.
Nog geen herstelpunten. De verzending moet minstens één keer na het inschakelen worden uitgevoerd. De eerste verzending vindt plaats binnen ongeveer vijf minuten.
Mijn doel valt buiten het beschikbare venster. De bewaring bedraagt 30 dagen, en het venster kan korter zijn als de verzending werd onderbroken. Het foutbericht geeft de exacte grenzen aan. Als het moment dat je nodig hebt is verlopen, val terug op een dagelijkse backup: zie Herstellen uit een backup.
Een restore is al aan de gang. Wacht tot het klaar is. De tabel toont de fase en voortgang.
De status toont een banner over de shipper. Je aanvraag is geregistreerd en het bericht verklaart de huidige staat. Niets gaat verloren.
Ik heb de bestanden terug nodig, niet de database. PITR kan niet helpen. Gebruik een bestandsback-up, en merk op dat een voltooide backup bestand voor bestand kan worden doorgebladerd in plaats van als geheel te worden hersteld.
Gerelateerde pagina's
- Een backup maken voor de dagelijkse bestands- en databaseback-ups die naast deze worden uitgevoerd.
- Herstellen uit een backup voor het pad voor volledige site-restore.
- Staging-omgevingen voor het testen van wijzigingen voordat deze productie bereiken.
- Site Security als het gegevensverlies werd veroorzaakt door een inbreuk in plaats van een fout.
Als je midden in een incident zit en niet zeker weet welk gereedschap je nodig hebt, neem contact met ons op via Support in KPanel of stuur een e-mail naar support@kapsulehost.com met de sitenaam en het moment waarop het probleem begon.