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.

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

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

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

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.