De backups van je servers

Er zijn twee soorten backup in CoreCP, en ze zijn van verschillende mensen. De backup van een hostingaccount is van de klant: die maakt hij zelf, naar zijn eigen opslag, en zet hij zelf terug (zie Je eigen backups). De backup van een server is van jou: de hele machine, met /etc, /home, elke database en de staat die CoreCP zelf bijhoudt.

Deze pagina gaat over de tweede soort. Je vindt hem onder Servers → Backups.

Eerst een bestemming, dan servers

Waar de backups van je vloot heen gaan leg je één keer vast, niet één keer per server. Onder Servers → Backups → Bestemmingen maak je een bestemming aan:

• de soort opslag — een rest-server, een sftp-server of S3;
• het adres van die opslag;
• het pad waaronder elke server een eigen plek krijgt;
• de inloggegevens, als de soort die nodig heeft.

Elke server krijgt onder dat pad een eigen repository. Dat is geen detail: restic ontdubbelt per repository, en in een gedeelde kan elke server bij de snapshots van alle andere — ook om ze te verwijderen. Het wachtwoord van zo'n repository wordt op de server zelf aangemaakt en verlaat hem nooit. Het paneel bewaart alleen de inloggegevens van de opslag.

Schrijf het repository-wachtwoord ergens buiten de server op. Zonder dat wachtwoord zijn de snapshots door niemand te lezen, ook niet door ons. Je vindt het op de server in /etc/corecp/secrets/backup.env.

Testen vóór je erop vertrouwt

Naast elke bestemming staat Valideer bestemming. Die vraagt eerst vanaf wélke server er gemeten moet worden, en dat is met opzet: of opslag bereikbaar is, is een eigenschap van de weg tussen één machine en die opslag. Een groen vinkje zonder machine erbij zegt niets.

De gekozen server loopt daarna een lijstje af — antwoordt de opslag, staat er een repository, en gaat er echt iets in — en schrijft daarvoor een kleine proefsnapshot die hij meteen weer weghaalt. Dat laatste is het punt: opslag die netjes antwoordt maar niet beschreven kan worden (een volle schijf, een read-only export, een S3-policy die alleen lezen toestaat) is precies wat deze knop moet vangen.

Faalt er een stap, dan staat er welke. In de terminal is het dezelfde meting:

corectl backup destination check --target sftp \
  --endpoint backup@storage.example.net --repo /srv/restic/stck1 --init

Welke bestemming? Het paneel stelt er een voor

Heb je meer dan één bestemming, dan hoef je niet uit je hoofd te weten welke de meeste ruimte heeft. Op de backuppagina van een server die nog nergens heen schrijft — en in de toevoegwizard, zodra de machine is aangemeld — staat een aanbeveling, met de metingen eronder waar hij op berust.

Die metingen zijn er vijf, in de volgorde waarin ze beslissen:

1. een andere locatie. Staat de opslag ergens anders dan de server zelf? Een snapshot naast de machine die hij beschermt overleeft een kapotte schijf, maar niet het gebouw. Een bestemming op dezelfde locatie wordt wél voorgesteld — onderaan, met een waarschuwing erbij.
2. wat de laatste proef zei. Een bestemming waarvan de laatste validatie mislukte komt onderaan en wordt nooit de aanbeveling.
3. vrije ruimte, gemeten op de opslagmachine zelf.
4. hoeveel servers er al heen schrijven — hoe minder, hoe beter verdeeld.
5. de gemeten afstand tussen deze server en die opslag.

Wat het paneel niet gemeten heeft, heet ook zo. "Vrije ruimte niet gemeten" telt niet als "genoeg ruimte" en ook niet als "te vol": het staat er precies tussenin. Zo werkt het ook voor een locatie die nergens is ingevuld.

Vrije ruimte en afstand bestaan alleen als het adres van de bestemming een machine is die dit paneel kent. Voor opslag bij een derde partij weet het paneel dat niet, en dan zegt het dat.

De bestemmingen die het niet werden staan eronder weggeklapt, elk met de reden. Een bestemming die helemaal niet gebruikt kán worden — van een andere servergroep, zonder opgeslagen inloggegevens, of de server zelf als opslag — staat er ook, met zoveel woorden.

Vul de locatie van een bestemming in (Servers → Backups → Bestemmingen) en van je servers, in je eigen woorden: "fra1", "ams-rack-3". Het paneel kijkt alleen of twee locaties gelijk zijn; leeg betekent onbekend.

Draait een server websites, databases of mailboxen en is er geen bestemming voor vastgelegd, dan zegt het serveradvies dat, met een knop naar diezelfde pagina.

Een server koppelen

Zet de backuprol aan op het configuratiescherm van de server, of kies een bestemming bij de backuprol in de toevoegwizard. Koppelen doet in één keer wat anders vier handelingen zijn: de rol installeren, de inloggegevens op de machine zetten, het doel in node.yaml schrijven en de repository aanmaken.

Bij een sftp-bestemming maakt de server zelf een sleutel aan en drukt de publieke helft af. Die zet je op de opslagmachine in authorized_keys — dat is de enige handeling die aan de andere kant hoort.

Voeg je de server via de wizard toe, dan bestaat de machine nog niet: de keuze wordt dan vastgelegd en de backuppagina van de server zegt daarna zelf dat er nog gekoppeld moet worden, met de knop ernaast.

Het tabblad Backups staat er ook op een server die géén backups maakt. Daar staat wat er waar is en welke bestemming het paneel aanraadt — juist die server is degene die je moet kunnen bereiken. Een schemaformulier krijg je er niet: zonder opslag zou de server elke wijziging toch weigeren.

Naar een andere opslag verhuizen doe je met Verplaatsen naar andere opslag, boven "Waar deze server heen schrijft". Let op wat dat wél en niet doet: de snapshots in de oude repository blijven daar staan — ze verhuizen niet mee en worden niet opgeruimd — en de eerste run naar de nieuwe opslag is een volledige, want daar is nog geen geschiedenis om op door te bouwen.

Schema, bewaartermijn en opruimen

Op Servers → server → Backups staan drie runs op een rij, in de volgorde waarin de nacht ze draait: de server, daarna de accounts, daarna het opruimen. Ze staan uit elkaar omdat de accountronde leest wat de serverronde net doorlopen heeft.

Elke run kies je als hoe vaak plus om hoe laat — "elke nacht om 01:00", "elke week op zondag om 04:00". Achter Geavanceerd staat de kalenderexpressie zelf; dat is letterlijk wat de server krijgt, en je hebt hem alleen nodig voor schema's die de knoppen niet kunnen zeggen (twee keer per nacht, alleen werkdagen, een lijst met datums). Onder elke run staat wanneer hij de volgende keer draait, uit het antwoord van de server zelf.

Een schema dat de server niet kan lezen wordt geweigerd, met de zin van de server eronder in het vak waar het over ging. Er wordt dan niets opgeslagen — je typefout kan geen timer stilzetten. Staat er tóch een timer stil (een server die van vóór deze versie komt, of een handmatig aangepast bestand), dan zegt de pagina dat met zoveel woorden in plaats van hem groen te tekenen.

Beginnen ze niet allemaal tegelijk?

Elke koppeling neemt de standaardtijd over, dus een vloot komt vanzelf op één minuut uit — en dan staan er tien servers tegelijk te schrijven naar dezelfde opslag. Valt deze server samen met buren op dezelfde bestemming, dan zegt het scherm dat: met wie hij samenvalt, op welke opslag, en welk tijdstip de rustigste plek in die nacht is met hoeveel minuten ruimte eromheen. Eén knop vult het in; opslaan doe je zelf.

Wat het paneel niet als gewone kloktijd kan lezen, telt het niet mee en zegt het erbij. Een advies dat die schema's stilzwijgend als vrije minuut zou behandelen, zou een tijdstip aanraden dat het nooit heeft nagekeken.

Hoe lang blijft een backup staan?

De bewaartermijn is vier groepen — dagelijks, wekelijks, maandelijks, en een bodem ongeacht datum. Ze gelden per groep: "7 dagelijks" betekent zeven dagen voor elk account én voor de serverlaag, niet zeven snapshots in totaal. En let op wat een getal in zo'n groep werkelijk betekent: "dagelijks 7" bewaart de laatste opname van elk van de laatste zeven dagen, niet de laatste zeven opnamen. Dat staat onder elk vak, zodat je het niet hoeft te onthouden.

Elke groep heeft een min en een plus, en onder de 1 kom je uit op geen — het woord, niet een getal. Dat is expres: "hier bewaren we niets uit" was een minteken van vijf pixels naast een 1, en die twee betekenen het tegenoverge- stelde van elkaar. De bodem is de uitzondering: zijn "uit" heet ook geen, en betekent simpelweg dat er geen ondergrens is — en hem op geen zetten haalt hem er echt af, zowel in een patroon als op het formulier van één server.

Alle vier uitzetten kan niet. Een bewaartermijn die niets bewaart wordt door de server geweigerd, mét de groep waar het over gaat erbij — het backupgereedschap weigert zo'n regel namelijk botweg, dus de opruimronde zou elke week falen zonder iets weg te halen, en niets op het scherm zou dat zeggen.

Eén regel voor de hele vloot

Vier getallen per server typen is precies hoe twee servers uit elkaar gaan lopen zonder dat iets het zegt. Op Servers → Backups → Bewaarpatronen leg je de regel één keer vast, geef je hem een naam, en koppel je er servers aan.

Een patroon wijzigen gaat in twee stappen, en de eerste is de belangrijkste. Opslaan legt de regel vast en raakt geen enkele server aan. Toepassen is de tweede druk, en vóórdat die gebeurt zegt het paneel wat er gaat gebeuren:

• hoeveel servers andere getallen krijgen dan ze nu hebben,
• hoeveel daarvan minder gaan bewaren — de richting waarin opnamen verdwijnen,
• en van hoeveel het paneel nog nooit een bewaartermijn heeft gelezen, wat geen van beide is en apart wordt geteld.

Is één server onbereikbaar, dan krijgen de andere de regel gewoon. Het verslag zegt welke server weigerde en wat hij zei, en één knop probeert het precies bij die server opnieuw. Er wordt niets teruggedraaid: een server die de getallen aannam heeft ze, en dat ongedaan maken omdat een ánder toestel weigerde zou een tweede wijziging zijn die niemand vroeg.

Op de pagina van een server zelf zie je welk patroon hij volgt en of hij de getallen ook echt heeft aangenomen. "Gekoppeld, maar nog niet op deze server" is een eigen antwoord — en het eerlijke antwoord voor een machine die sinds de koppeling onbereikbaar is.

Draait het opruimen eigenlijk nog?

De opruimronde kan stilletjes stuklopen. De meest voorkomende manier: hij neemt een exclusief slot op de repository, en een ronde die halverwege werd afgebroken laat dat slot achter — elke volgende ronde loopt er dan op stuk, terwijl de backups zelf gewoon blijven werken en de timers er gezond uitzien.

Daarom zegt de backuppagina van een server of de laatste opruimronde is afgerond, nog nooit heeft gedraaid, of mislukt is en waarmee. "Er is er nog nooit een geweest" is een eigen antwoord en telt nooit als gezond. De ronde ruimt nu zelf een slot op dat het backupgereedschap als achtergelaten beschouwt en probeert het opnieuw — al vóór zijn allereerste stap, want zo'n slot weigert zelfs een lezing van de repository; een slot dat een lopende ronde vasthoudt blijft precies waar het is.

De melding op die pagina verschijnt zodra er iets te zeggen valt, en daar horen de twee makkelijk gemiste bevindingen bij: een server die helemaal niets bewaart, en opslag die vol raakt. Valt er niets te zeggen, dan blijft de pagina stil.

Weigert je opslag verwijderen (een rest-server met --append-only), dan haalt opruimen vanaf deze server niets weg. Dat is geen storing maar de bedoeling: schrijven en wissen liggen expres niet bij dezelfde machine. Het scherm zegt het, en de bewaartermijn hoort dan op de opslagmachine te draaien.

Terugzetten

Terugzetten… laat je een snapshot kiezen. Standaard landt hij in een aparte map en blijft het draaiende systeem ongemoeid — dat is wat je wilt als je alleen wilt zien wat er vorige week in /etc stond.

Wil je over het draaiende systeem heen schrijven, dan moet je de naam van de server letterlijk typen. Het paneel vult die niet voor je in: een bevestiging die het paneel zelf kan produceren is geen bevestiging. Draai daarna een reconcile op die server, want de staat onder de diensten is veranderd.

Wie loopt er achter?

De lijst onder Servers → Backups staat op volgorde van achterstand: een server die nog nooit een snapshot maakte bovenaan, daarna de oudste. Een server zonder backuprol staat er ook op, met zoveel woorden — precies omdat "hij staat er niet bij" leest als "er is niets aan de hand".

Achterstand is dezelfde grens die de server zelf hanteert: corectl doctor keurt een machine af waarvan de nieuwste snapshot ouder is dan twee dagen. Eén gemiste nacht is een hik, twee is een patroon.

Wordt er getest of ze terug te lezen zijn?

Ja. Elke server met de backuprol haalt één keer per week automatisch een stuk uit zijn nieuwste momentopname, leest het na en gooit het weer weg. Op het backupscherm van de server staat wanneer dat voor het laatst goed ging; ging het mis, dan komt het in het overzicht met problemen te staan, met de melding van de server erbij. Een server die snapshots heeft en waarvan er nooit één is teruggelezen, is een belofte — dit maakt er een feit van.

Je kunt hem ook zelf draaien met Hersteltest nu draaien, en uitzetten met corectl backup configure --restoretest off.

Een eigen back-upserver die niets laat wissen

De veiligste bestemming is een CoreCP-back-upserver: een eigen server (in productie b1) die de backups van je andere servers bewaart en weigert er ooit één te verwijderen. Wie een van je servers overneemt, kan daarmee nieuwe snapshots schrijven, maar geen oude wissen of die van een andere server lezen.

1. Richt de back-upserver één keer in vanaf de terminal (zie hieronder). Daarna staat hij als gewone server in het paneel.
2. Kies onder Servers → Backups → Bestemmingen → Bestemming toevoegen de soort CoreCP-back-upserver en vul het adres in, bijvoorbeeld https://b1.example.net:8000. Een login vul je niet in: bij het koppelen geeft de back-upserver elke server een eigen login.
3. Koppel je servers zoals altijd. Het paneel vraagt de back-upserver om een login en een sleutel, en zet die op de server; het paneel bewaart ze zelf niet. Daarvoor heb je volledige toegang tot beide servers nodig.

Opruimen gebeurt op de back-upserver. Een gekoppelde server kan zelf niets meer weghalen; Opruimen op zijn pagina zegt dat ook. De back-upserver past elke nacht om 05:30 het bewaarbeleid toe dat je op de pagina van de server instelt — een wijziging daar gaat vanzelf mee. Hij rekent in tijdvakken ("alles van de laatste 7 dagen, één per dag") en niet in aantallen, zodat nep-snapshots de echte er niet uit kunnen duwen. Een beleid met alleen "bewaar de laatste N" wordt daarom geweigerd.

De controle Onveranderlijk op de servergezondheid is bij deze soort rood als de back-upserver tóch zou laten wissen.

Vanaf de terminal

Op de back-upserver:

corectl backup target serve                         # rest-server, alleen-toevoegen, TLS
corectl backup client add w1 --from 203.0.113.10    # login en sleutel voor w1, één keer getoond
corectl backup client set w1 --keep-daily 14        # bewaarbeleid van w1
corectl backup target prune --dry-run               # wat het opruimen zou weghalen
corectl backup target status

Op de server die er back-ups naartoe schrijft (de login en de sleutel lees je van stdin, nooit als argument):

corectl role add backup --target rest-append-only --endpoint https://b1.example.net:8000 --repo w1
corectl backup configure --ca-cert /etc/corecp/agent/ca.crt
corectl backup credential set --rest-user w1 --rest-password-stdin
corectl backup init
corectl backup target-key add --password-stdin

Elke --…-stdin volgt dezelfde regel: komt er niets binnen (een lege invoer of een afgebroken pijp), of geef je ook de gewone optie mee, dan weigert de server het commando in plaats van een leeg wachtwoord op te slaan. Per commando lees je er één waarde mee in.

De back-upserver houdt ook het paneel in de gaten en mailt als het langer dan de ingestelde tijd niet antwoordt:

corectl backup target watch --url https://p1.example.net --after 10m \
  --mail-to beheer@example.net --relay-host mail.example.net --test

De database van het paneel zelf gaat met pgBackRest naar dezelfde server; hoe je dat instelt staat in het herstelplan van het paneel.

Zie ook

• Een backup terugzetten — de reis van momentopname tot verificatie.
• Je eigen backups — de backup die een klant zelf maakt en terugzet.
• Een server toevoegen — waar de bestemming in de wizard staat.