Difference between revisions of "Backup"
| (10 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Geregeld worden er '''backups''' gemaakt van een groot deel van het systeem. Hier vallen onder andere de home directories en virtuele machines onder. De WebCie heeft ook een grote hoeveelheid incrementele databasebackups. | |
| − | + | ||
== Interne backups == | == Interne backups == | ||
| − | |||
| − | + | De interne backups zijn bedoeld om bestanden terug te kunnen halen die per ongeluk verwijderd zijn. Elke 4 uur, met middernacht als offset, wordt er een recursieve snapshot gemaakt van alle data. Deze 4 uurlijkse snapshots worden, op die van middernacht na, 2 dagen bewaard. De snapshots van middernacht worden standaard 2 weken bewaard, met enkele uitzonderingen zoals de home directories. Deze uitzonderingen plus hun retention tijd staan op haskell in `/etc/cron.daily/managesnapshot`. | |
| − | + | Deze 4 uurlijkse backups worden direct gesynced naar de on-site backup in de vorm van Nikola. | |
| − | + | Interne backups kunnen makkelijk teruggehaald worden. In het geval van een dataset is er in de root van deze dataset een onzichtbare map .zfs. In het geval van de home kan de staat van 20 november 2015 teruggevonden worden in `/srv/home/.zfs/snapshot/2015112000`. Dit kan alleen op haskell gedaan worden aangezien deze map niet bereikbaar is over NFS. Iets vergelijkbaars kan gedaan wordne met zvol's. Eerst moet echter de property snapdev op visible gezet worden in plaats van hidden en daarna zijn de snapshots van de zvols zichtbaar in `/dev`. Snapshots zijn read-only, dus als je een zvol probeert te mounten die dirty is, dan werkt dit niet als er ext4 op de zvol staat. Ext4 wil bij het recoveren namelijk schrijven, wat niet kan. In een dergelijke situatie kan het vaak handig zijn om een snapshot te klonen en dan te mounten. Met xfs is dit niet nodig. | |
| − | + | ||
| − | + | Momenteel worden backups van Stephen gemaakt met [https://github.com/psy0rz/zfs_autobackup ZFS Autobackup]. Om deze snapshots ook naar nikola te halen wordt er ook van deze package gebruik gemaakt. Hiervoor wordt er gebruik gemaakt van de zfs flag: ''autobackup:stephen-backup-nikola'' op stephen en het commando (op nikola) ''zfs-autobackup --ssh-source stephen stephen-backup-nikola storage/backup/stephen --progress --verbose'' voor het daadwerkelijk maken van de backup. Dit commando wordt elke dag om 00:00 uitgevoerd doormiddel van een cronjob | |
| − | + | == Off-site backups == | |
| − | + | We slaan de data ook off-site op bij de universiteit. Dit is een virtuele machine met de naam [[Claude|claude]]. Dit gebeurd vanaf Nikola(vroeger max), aangezien daar een 1:1 kopie staat van de data en op deze manier wordt haskell ontlast. De backups worden vanaf [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] gepulled vanaf Nikola en door Nikola eerst ge-gzipped en ge-encrypt, zodat de universiteit niet bij onze data kan. Naar [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] wordt elke eerste dag van de maand een complete kopie gedumped en voor de rest van de maand worden incrementele dumps gemaakt. | |
| − | + | ||
| − | + | ||
| − | == | + | == Relevante scripts == |
| − | + | De volgende scripts en crons die te maken hebben met backups zijn allemaal in gebruik. | |
| − | + | ||
| − | + | ||
| − | + | *`/usr/local/bin/backupscript` op Haskell maakt elke 4 uur (door `/etc/cron.d/autobackup`) een snapshot en stuurt deze direct naar Nikola. | |
| − | + | *`/etc/cron.daily/cleansnapshots` draait op zowel Nikola als Haskell en ruimt elke dag oude snapshots op. Deze file is identiek op beide machines, dus aanpassingen moeten gesynced worden. | |
| − | * | + | *`/usr/local/bin/pullbackups` op [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] pullt backups van Nikola en slaat deze op. |
| − | * | + | *`/usr/local/bin/cleanbackups`op [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] ruimt oude snapshots op als de ruimte (2TB) vol dreigt te raken. Vol is >90%. Dit is een cron die elke 5 minuten checkt. Mocht er iets fout gaan zoals dat er bij het opruimen niet tenminste 1 volledige backup altijd bewaard blijft, dan mailt deze dit. Het gebeurd nog wel eens dat de nfs share van de universiteit eruit knalt, en dan flipt dit script ook. |
| − | * | + | |
| − | == | + | == WebCie: snapshots van de database == |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Op de vm-www maakt een script automatisch elke 10 minuten een dump van de database. Een diff met de vorige db-dump wordt opgeslagen in het archief (<code>haskell:/srv/www/archief</code>): vanaf de [[vm-www]] beschikbaar op <code>/archief/www/2018-08/07/whoswho4.2018-08-07_13_00.diff</code> bijvoorbeeld. Ook wordt elke dag een volledige db-dump opgeslagen. Elke maand worden de volledige dumps en alle diffs samen gecomprimeerd. De dumps kun je gebruiken om per ongeluk gewiste data weer terug te zetten. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | === | + | === Backup van binaire logs === |
| − | + | ||
| − | + | Omdat het diffprogramma soms te lang deed over het backuppen omdat de diffs heeeeeeeeel lang werden, gaan we de binaire logs gebruiken voor backups. | |
| − | * | + | |
| − | * | + | Als je in de mysql-configuratie de optie log-bin aanzet, zal mysql alle updates aan de databases opschrijven in een logbestand. Dit kun je gebruiken voor [[replicatie]], of voor backups. Elke 10 minuten worden de logs geflusht en alle nieuwe bestanden gekopieerd naar het www-archief. Vervolgens worden de oude logbestanden weggegooid (zodat we niet de volledige geschiedenis steeds opnieuw overnemen). PAS OP: als je replicatie doet en een andere server is offline terwijl de logs worden weggegooid, kan die niet zomaar meer up-to-date komen! Zodra je weer replicatie wilt aanzetten (zoals [[Webcie-vm#Mariadb_en_replicatie|als je een nieuwe VM wilt maken]], moet je dus een goede oplossing hiervoor verzinnen. (Misschien: houd bij welke logbestanden al gekopieerd zijn en sla die over?) |
| + | |||
| + | * https://dev.mysql.com/doc/refman/8.0/en/backup-methods.html | ||
| + | * https://dev.mysql.com/doc/refman/8.0/en/binary-log.html | ||
| + | * https://dev.mysql.com/doc/refman/8.0/en/point-in-time-recovery.html | ||
| + | |||
| + | === Encryptie van de backups === | ||
| + | |||
| + | Alle WebCie backups worden nu encrypted opgeslagen. De public key die hier voor gebruikt wordt is de "A-Eskwadraat Backup Service <webcie@a-eskwadraat.nl>" key. Deze public key staat geregistreerd in de keychain van de apache user op de vm-www2. Daarnaast is de public key te vinden in [deze](https://gitlab.com/iba-aes/webcie/website/snippets/1835239) Gitlab snippet. De private key wordt bewaard door het bestuur en de WebCie voorzitter. | ||
| + | |||
| + | === Decrypten van data === | ||
| + | |||
| + | Is het nodig om de data te decrypten? Volg het volgende stappenplan. | ||
| + | |||
| + | * Vraag het bestuur/de WebCie voorzitter om de USB stick met de private key. | ||
| + | * Importeer de private key: `gpg --import <keynaam>` | ||
| + | * Decrypt de data: `gpg --output <outputfile> --decrypt <inputfile>` | ||
| + | * Verwijder de private key nadat je klaar bent: `gpg --delete-secret-key webcie@a-eskwadraat.nl` | ||
| + | |||
| + | [[Category:Sysop]] | ||
| + | [[Category:WebCie]] | ||
Latest revision as of 22:05, 31 May 2021
Geregeld worden er backups gemaakt van een groot deel van het systeem. Hier vallen onder andere de home directories en virtuele machines onder. De WebCie heeft ook een grote hoeveelheid incrementele databasebackups.
Contents
Interne backups
De interne backups zijn bedoeld om bestanden terug te kunnen halen die per ongeluk verwijderd zijn. Elke 4 uur, met middernacht als offset, wordt er een recursieve snapshot gemaakt van alle data. Deze 4 uurlijkse snapshots worden, op die van middernacht na, 2 dagen bewaard. De snapshots van middernacht worden standaard 2 weken bewaard, met enkele uitzonderingen zoals de home directories. Deze uitzonderingen plus hun retention tijd staan op haskell in `/etc/cron.daily/managesnapshot`.
Deze 4 uurlijkse backups worden direct gesynced naar de on-site backup in de vorm van Nikola.
Interne backups kunnen makkelijk teruggehaald worden. In het geval van een dataset is er in de root van deze dataset een onzichtbare map .zfs. In het geval van de home kan de staat van 20 november 2015 teruggevonden worden in `/srv/home/.zfs/snapshot/2015112000`. Dit kan alleen op haskell gedaan worden aangezien deze map niet bereikbaar is over NFS. Iets vergelijkbaars kan gedaan wordne met zvol's. Eerst moet echter de property snapdev op visible gezet worden in plaats van hidden en daarna zijn de snapshots van de zvols zichtbaar in `/dev`. Snapshots zijn read-only, dus als je een zvol probeert te mounten die dirty is, dan werkt dit niet als er ext4 op de zvol staat. Ext4 wil bij het recoveren namelijk schrijven, wat niet kan. In een dergelijke situatie kan het vaak handig zijn om een snapshot te klonen en dan te mounten. Met xfs is dit niet nodig.
Momenteel worden backups van Stephen gemaakt met ZFS Autobackup. Om deze snapshots ook naar nikola te halen wordt er ook van deze package gebruik gemaakt. Hiervoor wordt er gebruik gemaakt van de zfs flag: autobackup:stephen-backup-nikola op stephen en het commando (op nikola) zfs-autobackup --ssh-source stephen stephen-backup-nikola storage/backup/stephen --progress --verbose voor het daadwerkelijk maken van de backup. Dit commando wordt elke dag om 00:00 uitgevoerd doormiddel van een cronjob
Off-site backups
We slaan de data ook off-site op bij de universiteit. Dit is een virtuele machine met de naam claude. Dit gebeurd vanaf Nikola(vroeger max), aangezien daar een 1:1 kopie staat van de data en op deze manier wordt haskell ontlast. De backups worden vanaf claude gepulled vanaf Nikola en door Nikola eerst ge-gzipped en ge-encrypt, zodat de universiteit niet bij onze data kan. Naar claude wordt elke eerste dag van de maand een complete kopie gedumped en voor de rest van de maand worden incrementele dumps gemaakt.
Relevante scripts
De volgende scripts en crons die te maken hebben met backups zijn allemaal in gebruik.
- `/usr/local/bin/backupscript` op Haskell maakt elke 4 uur (door `/etc/cron.d/autobackup`) een snapshot en stuurt deze direct naar Nikola.
- `/etc/cron.daily/cleansnapshots` draait op zowel Nikola als Haskell en ruimt elke dag oude snapshots op. Deze file is identiek op beide machines, dus aanpassingen moeten gesynced worden.
- `/usr/local/bin/pullbackups` op claude pullt backups van Nikola en slaat deze op.
- `/usr/local/bin/cleanbackups`op claude ruimt oude snapshots op als de ruimte (2TB) vol dreigt te raken. Vol is >90%. Dit is een cron die elke 5 minuten checkt. Mocht er iets fout gaan zoals dat er bij het opruimen niet tenminste 1 volledige backup altijd bewaard blijft, dan mailt deze dit. Het gebeurd nog wel eens dat de nfs share van de universiteit eruit knalt, en dan flipt dit script ook.
WebCie: snapshots van de database
Op de vm-www maakt een script automatisch elke 10 minuten een dump van de database. Een diff met de vorige db-dump wordt opgeslagen in het archief (haskell:/srv/www/archief): vanaf de vm-www beschikbaar op /archief/www/2018-08/07/whoswho4.2018-08-07_13_00.diff bijvoorbeeld. Ook wordt elke dag een volledige db-dump opgeslagen. Elke maand worden de volledige dumps en alle diffs samen gecomprimeerd. De dumps kun je gebruiken om per ongeluk gewiste data weer terug te zetten.
Backup van binaire logs
Omdat het diffprogramma soms te lang deed over het backuppen omdat de diffs heeeeeeeeel lang werden, gaan we de binaire logs gebruiken voor backups.
Als je in de mysql-configuratie de optie log-bin aanzet, zal mysql alle updates aan de databases opschrijven in een logbestand. Dit kun je gebruiken voor replicatie, of voor backups. Elke 10 minuten worden de logs geflusht en alle nieuwe bestanden gekopieerd naar het www-archief. Vervolgens worden de oude logbestanden weggegooid (zodat we niet de volledige geschiedenis steeds opnieuw overnemen). PAS OP: als je replicatie doet en een andere server is offline terwijl de logs worden weggegooid, kan die niet zomaar meer up-to-date komen! Zodra je weer replicatie wilt aanzetten (zoals als je een nieuwe VM wilt maken, moet je dus een goede oplossing hiervoor verzinnen. (Misschien: houd bij welke logbestanden al gekopieerd zijn en sla die over?)
- https://dev.mysql.com/doc/refman/8.0/en/backup-methods.html
- https://dev.mysql.com/doc/refman/8.0/en/binary-log.html
- https://dev.mysql.com/doc/refman/8.0/en/point-in-time-recovery.html
Encryptie van de backups
Alle WebCie backups worden nu encrypted opgeslagen. De public key die hier voor gebruikt wordt is de "A-Eskwadraat Backup Service <webcie@a-eskwadraat.nl>" key. Deze public key staat geregistreerd in de keychain van de apache user op de vm-www2. Daarnaast is de public key te vinden in [deze](https://gitlab.com/iba-aes/webcie/website/snippets/1835239) Gitlab snippet. De private key wordt bewaard door het bestuur en de WebCie voorzitter.
Decrypten van data
Is het nodig om de data te decrypten? Volg het volgende stappenplan.
- Vraag het bestuur/de WebCie voorzitter om de USB stick met de private key.
- Importeer de private key: `gpg --import <keynaam>`
- Decrypt de data: `gpg --output <outputfile> --decrypt <inputfile>`
- Verwijder de private key nadat je klaar bent: `gpg --delete-secret-key webcie@a-eskwadraat.nl`
