Je eigen backups

Je hostingbedrijf maakt vrijwel zeker backups van de hele server. Die zijn er voor rampen — een kapotte schijf, een verloren machine. Ze zijn niet bedoeld om jou op dinsdagmiddag terug te helpen omdat een plugin-update je site sloopte. Dáárvoor zijn je eigen backups: jij bepaalt wanneer ze gemaakt worden, waar ze staan en wanneer je ze terugzet.

Beeld — Paneel → Hosting → Accounts → jouw account → Bestanden, FTP en backups → Backups. Schermafdrukken worden gemaakt met openwolf designqc en staan in .wolf/designqc-captures/.

Wat er in een backup zit

Eén backup van je account bevat:

• je bestanden — alles onder je home, dus ook je websites;
• je databases, als dumps;
• je mailboxen, met de berichten erin;
• je DNS-zones, als die op deze server staan.

Je kunt onderdelen overslaan als je ze niet nodig hebt — mailboxen zijn vaak het grootste stuk en veranderen het minst interessant.

Twee mappen gaan er bewust niet in mee:

• backups/ — je eerdere backups. Anders zou elke backup alle vorige met zich meedragen en elke nacht groter worden.
• .trash/ — je prullenbak. Wat je hebt weggegooid hoort niet in een backup: die zou groeien bij elke verwijdering, en bij een terugzetactie zouden je verwijderde bestanden weer terugkomen. Wil je iets uit je prullenbak bewaren, zet het dan éérst terug — dan zit het bij de volgende backup gewoon in je bestanden.

Wat je pakket toestaat

Bovenaan de pagina staat Wat het pakket toestaat: hoeveel backups je per dag mag maken, hoeveel er bewaard mogen blijven, hoeveel bestemmingen je mag opslaan en welke soorten bestemmingen zijn toegestaan. Die grenzen worden op de server afgedwongen, niet in het scherm: vraag je meer dan mag, dan krijg je de toegestane waarde terug, geen foutmelding.

Staat er Eigen backups staan uit voor dit account, dan heeft je reseller of beheerder ze in het pakket niet aangezet. Daar vraag je het aan.

corectl userbackup status --account web1

Waar die grenzen vandaan komen

De limieten komen uit vier lagen. De onderste geldt als niemand iets zegt, de bovenste wint:

De standaard is 3 backups bewaren, 4 bestemmingen, 1 per dag voor een gewoon hostingaccount. Ben je zelf reseller, dan is het 7 / 6 / 2 — je zet immers ook backups terug voor je eigen klanten.

corectl userbackup status en de kolom Herkomst in het paneel zeggen per regel welke laag hem bepaalde. Staat er Hier ingesteld, dan heeft je hostingbedrijf speciaal voor jou iets afgesproken — dat kan ook méér zijn dan het pakket geeft:

corectl userbackup policy show --account web1

Waarom er geen limiet in GB is

Er staat bewust geen maximum in gigabytes op je backups.

• Een externe bestemming — je eigen S3-bucket, je NAS, je Dropbox — is jouw opslag. Wat daar past bepaal jij, niet wij.
• Een lokale backup staat in ~/backups, dus binnen je account. Die telt gewoon mee in het schijfquotum dat je toch al hebt. Zit je quotum vol met backups, dan is je quotum vol — dat zie je op je accountpagina staan en je lost het op door backups te verwijderen of ruimte bij te kopen.

Wat je pakket wél begrenst is het aantal kopieën, het aantal bestemmingen en hoe vaak je een backup maakt.

Welke server jouw platformback-up maakt

Boven de lijst kan één regel staan: "De platformback-up van dit account wordt gemaakt door …". Die verschijnt alleen als de back-uprol van je account bij een andere machine ligt dan waar je bestanden staan.

Dat is een ander antwoord dan de bestemming hieronder: de bestemming is de opslagplek, dit is de server die ernaartoe schrijft. Voor je eigen back-ups verandert er niets — die worden gemaakt op de machine waar je bestanden staan.

Bestemmingen: waar de backups heen gaan

Er is altijd één bestemming die het al doet: lokaal, in ~/backups. Handig en snel — maar hij staat op dezelfde server als je site. Voor "ik heb per ongeluk mijn database geleegd" is dat prima. Voor "de server is weg" niet.

Zet er daarom minstens één externe bestemming naast. Ondersteund worden:

Klik Bestemming toevoegen, kies een type en vul de velden in die daarbij horen. De inloggegevens gaan één keer naar de server en worden daar versleuteld bewaard; het paneel houdt er geen kopie van.

# S3-compatibele opslag
corectl userbackup dest add offsite --account web1 --type s3 \
  --endpoint s3.eu-central-1.wasabisys.com --region eu-central-1 \
  --bucket mijn-backups --access-key AKIA… --secret-key-stdin < ~/secret.txt

# een eigen NAS over SSH
corectl userbackup dest add nas --account web1 --type sftp \
  --host nas.thuis.nl --port 22 --user backup --path /volume1/hosting --key-file ~/.ssh/id_ed25519

corectl userbackup dest list --account web1
corectl userbackup dest remove nas --account web1

Een bestemming verwijderen wist de inloggegevens; de backups die er al staan blijven gewoon staan.

Nu een backup maken

Klik Nu een backup maken en kies de bestemming. Je ziet de voortgang, en als het klaar is verschijnt de backup in de lijst met datum, grootte en een id.

corectl userbackup create --account web1 --dest offsite --keep 5
corectl userbackup create --account web1 --dest local --no-mail   # zonder de mailboxen
corectl userbackup list   --account web1 --dest offsite

--keep ruimt na afloop op: hij houdt de nieuwste N backups op die bestemming en gooit de rest weg, binnen wat je pakket toestaat.

Automatisch, elke nacht

Onder Schema stel je per bestemming in wanneer het vanzelf gebeurt. Het veld is een gewone cron-regel van vijf velden.

# elke nacht om 03:30, en houd er vijf
corectl userbackup schedule --account web1 --dest offsite --cron "30 3 * * *" --keep 5

# elke zondag om 04:00
corectl userbackup schedule --account web1 --dest nas --cron "0 4 * * 0" --keep 8

corectl userbackup schedule --account web1 --dest offsite --off   # schema weghalen

Vijf velden: minuut · uur · dag van de maand · maand · dag van de week. Zet hem 's nachts; een backup van een grote site kost schijf-I/O die je bezoekers merken.

Onder Recente runs zie je van elke geplande run of hij gelukt is. Blijf daar af en toe naar kijken — een schema dat al drie weken faalt is erger dan geen schema, want je dacht dat je gedekt was.

Terugzetten

Kijk eerst wat het zou doen. Klik Proefdraaien: het paneel toont welke bestanden, databases en mailboxen zouden worden overschreven, zonder iets te veranderen.

corectl userbackup restore --account web1 --id <backup-id> --dest offsite --dry-run

Ben je akkoord, dan kies je Herstellen. Herstellen overschrijft de huidige bestanden, databases en mailboxen van dit account. Er is geen "samen mengen": wat in de backup zit wint.

corectl userbackup restore --account web1 --id <backup-id> --dest offsite
corectl userbackup restore --account web1 --id <backup-id> --no-mail --no-dns

Wil je alleen je database terug en niet je bestanden, gebruik dan --no-mail en houd je bestanden erbuiten door in plaats hiervan de dump uit de backup te pakken — zie Databases en phpMyAdmin voor het importeren.

Een backup weggooien:

corectl userbackup remove --account web1 --id <backup-id> --dest offsite

Eén ding terugzetten in plaats van alles

Meestal is er niets kapot behalve één ding: één bestand dat je overschreef, één tabel die je per ongeluk leegde, één mailbox die weg is. Het hele account terugzetten kost je dan alles wat er sindsdien gebeurd is — de bestellingen van vanmiddag, de mail van vanochtend. Dat hoeft niet.

Kijk eerst wat er in een backup zit. Dit leest de backup zelf, verandert niets, en zegt er per onderdeel bij wat terugzetten zóu doen:

corectl backup items web1
corectl backup items web1 --kind database
corectl backup items web1 --path domains/voorbeeld.nl/public_html

Er zijn zes soorten onderdelen: een bestand, een map, een database, een mailbox, een DNS-zone en je crontab. Zet er één terug met het soort en de naam die je in de lijst zag:

# eerst proefdraaien: dit schrijft niets
corectl backup restore item web1 --kind file \
  --name domains/voorbeeld.nl/public_html/index.php --dry-run

# en dan echt
corectl backup restore item web1 --kind file \
  --name domains/voorbeeld.nl/public_html/index.php
corectl backup restore item web1 --kind database --name web1_shop
corectl backup restore item web1 --kind mailbox --name info@voorbeeld.nl

Drie dingen die je mag aannemen, en die getest zijn:

• Alleen dat ene ding verandert. Zet je één bestand terug, dan blijft het bestand ernaast precies zoals het was. Een map wordt samengevoegd: wat je ná de backup hebt toegevoegd blijft staan.
• Proefdraaien is echt proefdraaien. --dry-run noemt het onderdeel, zegt of het wordt aangemaakt of overschreven, en laat de server ongemoeid.
• Twee keer terugzetten is hetzelfde als één keer. Je kunt hetzelfde commando gerust nog eens draaien; je eindigt nooit halverwege.

Werkt zo'n commando niet, dan bewaart jouw hostingbedrijf geen backups van dit account of stelt het ze niet aan jou beschikbaar. Vraag het ze — zij kunnen hetzelfde terugzetten vanuit het paneel, met het scherm hieronder.

Terugzetten uit een backup (het scherm)

Dit scherm is er voor je hostingbedrijf en je reseller. Zie je het niet, dan is dat geen storing: het leest óók de backups die het platform van jouw account maakt, en die zijn van je hostingbedrijf. Vraag hen om één ding terug te zetten, of doe het zelf met de commando's hierboven.

Beeld — Paneel → Hosting → Accounts → het account → Backups → Backup doorbladeren.

Het scherm doet vier dingen, in deze volgorde.

1. Je kiest een backup. Bovenaan staat een balk met alle backups van dit account die open te maken zijn: de platformbackups (die maakt het hostingbedrijf, buiten de schijfruimte van de klant om) en de eigen backups van het account. Staat een eigen backup op een externe bestemming, dan staat hij er wel bij maar kun je hem niet per onderdeel openen — hij ligt niet op de server. Zo'n backup zet je in zijn geheel terug via het gewone backupscherm.

2. Je bladert erdoorheen. De lijst toont de zes soorten uit één backup — bestand, map, database, mailbox, DNS-zone en crontab — met per rij wat terugzetten zóu doen: aanmaken (er is nu niets) of overschrijven (er staat al iets). Een map klik je open om een niveau dieper te kijken; er wordt telkens maar één niveau opgehaald, dus een home met tienduizenden bestanden blijft werkbaar. Rechtsboven de lijst kies je één soort tegelijk. Klik je op een rij, dan schuift een paneel open met alle details: waar het terugkomt, hoe groot het is, wanneer het voor het laatst gewijzigd is.

3. Je draait eerst proef. Vink aan wat je terug wilt en druk op Proefdraaien. De server loopt dan precies dezelfde stappen door als een echte restore en slaat alleen het schrijven over. Wat je daarna ziet, is dus geen schatting: het is wat er gaat gebeuren, per onderdeel, met "aanmaken" of "overschrijven" erbij. Er is vóór dit moment geen enkele knop die iets terugzet — dat is met opzet zo.

4. Pas daarna zet je het echt terug. Onder de proefdraai staat de knop. Komt er niets overheen, dan is één bevestiging genoeg. Wordt er wél iets overschreven, dan vraagt het paneel je de accountnaam over te typen — dezelfde drempel als bij elke andere handeling die gegevens vervangt. Daarna loopt elk onderdeel als een taak op de server, en de voortgang komt live binnen; je kunt de pagina gerust verlaten.

Wat je mag aannemen, en wat getest is:

• Alleen het gekozen onderdeel verandert. Het bestand ernaast, de tweede database, de andere mailbox: die blijven zoals ze nu zijn.
• Je ziet nooit de backups van iemand anders. Het scherm toont uitsluitend de backups van het account in de adresbalk, en de server weigert een archief dat van een ander account is.
• Proefdraaien schrijft niets. Een verwijderd bestand blijft na het proefdraaien nog steeds verwijderd.

De drie regels die backups echt laten werken

1. Eén kopie is geen backup. Lokaal én ergens anders.
2. Een backup die je nooit teruggezet hebt, is een aanname. Doe één keer per jaar een proefherstel — desnoods op een testomgeving.
3. Kijk naar de runs. Een stille storing merk je pas als je hem nodig hebt.

Als er iets niet klopt

Wat er met extra namen en subdomeinen gebeurt

Een backup van je account bewaart je websites zoals ze zijn — inclusief de dingen die je aan een naam alleen niet kunt zien:

• extra namen komen terug zoals je ze had: of ze de site tonen of doorsturen, of hun post naar je hoofddomein gaat, en of deze server hun DNS-zone had;
• subdomeinen komen terug als subdomein van hun hoofddomein, en op dezelfde plek op de schijf. Dat laatste is belangrijk als je ooit van DirectAdmin bent gemigreerd: je subdomein staat dan in de map van het hoofddomein, en een terugzetactie die het ergens anders neerzette zou elke link naar die map breken.

Je hoeft daar niets voor te doen. Een backup die vóór deze functie is gemaakt kun je gewoon terugzetten: die kent de extra namen alleen als losse namen, en die komen dan terug als "toon dezelfde site, met de post erbij" — wat ze waren.

Zie ook

• Bestanden, FTP en SSH — waar ~/backups staat.
• Databases en phpMyAdmin — één database terugzetten in plaats van alles.
• Een testomgeving maken — oefenen zonder je live site te raken.

Een backup terugzetten die van ergens anders komt

Zet je een archief terug dat níet van dit paneel komt — een export van je vorige hoster, een tar die je zelf hebt bewerkt — dan wordt dat archief als onbetrouwbaar behandeld. Dat is geen wantrouwen richting jou; het is dat een archief bestandsnamen kan bevatten die buiten je eigen map wijzen, en een terugzetactie die dat gewoon uitvoert schrijft in andermans gegevens.

Wat er gebeurt voordat er ook maar één bestand wordt weggeschreven:

• Namen die buiten je eigen map wijzen (../../ergens/anders) worden geweigerd.
• Snelkoppelingen in het archief worden gecontroleerd vóór ze worden aangemaakt.
• Rechten uit het archief worden teruggebracht tot gewone lees- en schrijfrechten; een archief kan geen bijzondere rechten binnensmokkelen.
• Een archief dat zichzelf uitpakt tot een veelvoud van zijn grootte loopt tegen je eigen schijfruimte aan en niet tegen die van de server.

Kijk eerst wat er zou gebeuren, zonder iets terug te zetten:

ssh root@stck1.corecp.dev 'corectl backup restore --account acc-1 \
  --archive /var/backups/corecp/acc-1/acc-1-20260814.tar.zst --dry-run'

would restore 18422 member(s) into /home/acc-1
0 member(s) would be refused (link target outside the account tree)

Staat er een aantal groter dan nul achter refused, dan worden die bestanden overgeslagen en krijg je ze bij naam te zien. Ze worden niet stilletjes weggelaten — een terugzetactie die zwijgend bestanden laat vallen is erger dan één die stopt.

Zien hoe ver een back-up is

Loopt er een back-up, dan hoef je niet te gokken. Elke handeling die je paneel op een server start, staat in de takenlijst (zie Achtergrondtaken volgen), en back-ups horen daarbij.

Wat je daar ziet, hangt af van wat er te tellen valt:

• Een back-up van één account — die van jou — telt niets dat zinvol af te meten is. Je ziet dus bezig sinds 09:41 en de duur die oploopt, en geen voortgangsbalk. Dat is met opzet: een balk die op tijd is gebaseerd in plaats van op werk, staat op 80% terwijl er nog een half uur te gaan is.
• Een back-up van alle accounts op een server (beheerderswerk) telt wél: 3 van de 11 accounts. Die teller loopt alleen vooruit.

# Beheerders, op het paneel:
root@panel1:~# corecp-panel tasks list --active
STARTED              SOURCE  OPERATION        SUBJECT  NODE              STATE    PROGRESS       DURATION
2026-08-17 09:41:02  node    backup.accounts  -        stck1.corecp.dev  running  3/11 accounts  1m48s

Let op het verschil tussen twee bewaartermijnen: het paneel bewaart de regel 90 dagen, de server bewaart het bijbehorende logboek 30 dagen. Een back-up van twee maanden geleden staat dus nog in de lijst en meldt dan eerlijk "het logboek is op de server verlopen" in plaats van een lege pagina te tonen.

Waar het proefdraaien nu staat

Proefdraaien laat zien wat een terugzetting zou veranderen zonder iets te veranderen. Dat overzicht stond op de pagina achter het geopende paneel — de enige plek die je op dat moment niet kunt zien. Het staat nu in het paneel zelf, met de kopieerknop erbij.

Weigert de server iets — een bestemming die hij niet accepteert, een backup die hij niet kan terugzetten — dan blijft het venster staan met die reden erin, boven het veld of de knop waar het over gaat.

Wat de beheerder los van jouw backups bewaart

Jouw backup gaat over jouw account: je bestanden, je databases, je mailboxen en je instellingen. Daarnaast maakt de beheerder een backup van de server als geheel. Daar zit de administratie van de server zelf in — de maillijst waaruit de mailserver leest, de zonegegevens en de webmail-instellingen — en die valt buiten jouw backup omdat het niet van jou is.

Wat dat voor jou betekent:

• Ben je één mailbox of één database kwijt, dan is jouw eigen backup het antwoord; die zet je zelf terug.
• Is er iets met de server aan de hand, dan heeft de beheerder een eigen kopie van wat de server nodig heeft om te werken. Je hoeft daar niets voor te doen en je hoeft er ook niets voor te bewaren.

Wil je zeker weten dat je eigen backup actueel is, kijk dan in het overzicht wanneer de laatste klaar was — of vraag het op de opdrachtregel als je die gebruikt:

corectl backup list --account jouwgebruiker

De datum die je daar ziet, is het moment waarop de kopie compleet was, niet het moment waarop hij begon.

Als een backup elke nacht blijft duren

Je backup draait binnen je eigen account, met dezelfde grenzen als je websites: hetzelfde CPU-plafond, hetzelfde geheugen, hetzelfde maximum aantal processen. Dat is met opzet zo — het is de reden dat een grote backup de websites van de andere klanten op de server niet kan vertragen — en het heeft één gevolg dat de moeite waard is om te weten.

Als de server je account tijdens de backup bij zijn CPU-plafond tegenhoudt, duurt de backup langer. Niet een beetje langer: het kan het verschil zijn tussen twintig minuten en de hele nacht.

Je kunt zien of dat gebeurt. Ga naar Account → Verbruik en grenzen en kijk naar het uur waarin de backup draaide. Werd je account op dat uur afgeremd, dan noemt de momentopname het proces — en als dat de backup is, is dit een vraag over je pakket en niet een probleem met de backup.

Zie "Verbruik en grenzen" voor wat je dan kunt doen.