Intussen is er al een tijdje een nieuwe versie van Nextcloud uit, en na een paar dagen afwachten durf ik een update wel aan. Ik draai tegenwoordig de gecontaineriseerde versie, dus meestal is dat een kwestie van docker-compose pull && docker-compose down && docker-compose up -d. Easy peasy. Ik dacht vanmorgen dat wel even in de achtergrond aan te kunnen slingeren terwijl ik met werk bezig was.
Dat dacht ik dus verkeerd...
Na een tijdje zag ik ergens een notificatie langskomen dat Nextcloud down was. Meestal duurt zo'n update niet lang en als je al een down-melding ziet, is dat van korte duur. Nu bleef de boel echter down. Hm.
Stap 1: Logs bekijken
De logs mekkeren iets over ontbrekende database-tabellen. Op zich wat apart, maar goed, het kan, het is een major nieuwe versie dus misschien zijn er wat tabellen bijgekomen, of zo.
Stap 2: Met de command-line tool kijken of er iets van een migratie moet worden afgetrapt.
Eh, command-line tool gaat luidkeels en spectaculair stuk op het volledig ontbreken van databases. OK, tijd voor een licht gevoel van onbehagen...
Stap 3: Even adminer ernaast parkeren om te zien wat er met die database aan de hand is.
Adminer is wat PHPMyAdmin ooit was, een handig en niet te zwaar stuk gereedschap om een database te benaderen. Extra container in de stack erbij, en gaan met die banaan:
adminer:
image: adminer
depends_on:
- db
ports:
- "8083:8080"Adminer opentrekken in een browser, inloggen, en...
Eh. Fuck. "No tables", that ain't good.
Stap 4: Koffie
Mmm, koffie.
Stap 5: Gelukkig heb ik een backup!
Ik laat elke nacht een mysqldump naar een bestand trekken, en dat bestand wordt meegenomen in de dagelijkse off-site backups van Duplicati, dus nou ja, dan hark ik daar dat bestand uit en zet ik de boel weer terug. Makkie!
Althans, dat is het idee. Het daadwerkelijke bestand is namelijk 0 (nul) bytes groot, in plaats van de tientallen MB's die ik verwacht. En blijkbaar gaat die dump al een tijdje mis, dus, eh, geen backup.
Stap 6: Milde paniekaanval, meer koffie
Er zijn nu nog twee opties; ofwel de data staat mogelijk nog ergens in een Docker-volume (of een snapshot daarvan, want ik gebruik btrfs) te slingeren... of ik ben het echt kwijt.
In dat laatste geval heb ik natuurlijk de bestanden zelf nog wel; wat er in de database staat, is metadata zoals gebruikers, gedeelde bestanden, maar ook data van applicaties zoals de agenda en contacten. Die laatste twee heb ik op mijn telefoon en computers (want dat synct uiteraard allemaal met elkaar) en dat kan ik makkelijk exporteren en in een eventuele nieuwe database weer importeren. De metadata van bestanden is... iets vervelender, maar niet onoverkomelijk, hoewel missende gebruikers wel wat lastiger zijn.
Goed, maar eens kijken of er nog iets in een volume rondslingert. Eerst ontdekken hoe dat volume heet, dus even speuren in het docker-compose-bestand.
...waarin ik blijkbaar nooit een aparte container voor de data van MariaDB heb gedefinieerd, dus dat zou betekenen dat die data in de container zelf wordt bewaard, en dus verloren gaat als die container wordt weggegooid. Iets wat waarschijnlijk is gebeurd bij de update-poging, en wat dus de lege databases verklaart.
Fuckfuckfuckfuck fuck fuckity-fucknuggets.
Stap 7: Speuren!
Docker slaat standaard zijn spul op onder /var/lib/docker. Elke container (onder containers/) heeft een prachtig ID, en verder niks. Daar kan ik dus niet op afgaan, en ik draai nogal wat containers. Elke container kan weer wat volumes hebben (onder, je raadt het al, volumes/) en dat zijn er nog meer.
Gelukkig heeft MariaDB een standaard directory-indeling (geërfd van MySQL), en kan ik dus zoeken op een bestand genaamd ibdata1:
find /var/lib/docker/volumes -name ibdata1...dat levert drie hits op, en alledrie bevatten ze een directory nextcloud/, wat betekent dat in die server-omgeving een database met die naam bestaat. En één van de drie heeft daar ook een hele sloot bestanden in staan die de tabellen omvatten! Opluchting! Dit gaat helemaal goedkomen!
Stap 8: De data weer terugzetten
De volgende paar stappen zijn nu vrij eenvoudig:
- ik zorg ervoor dat de database-container een apart volume krijgt om de data in te stallen, zodat die bij een eventuele update niet meer wegvalt
- daarna start ik die container kort (en stop ik hem weer), zodat het volume wordt gemaakt
- tenslotte hoef ik dan alleen nog maar de data uit het oude volume naar het nieuwe volume te schuiven en de container opnieuw op te starten
Dat werkt zoals gepland, en al snel is de database in al zijn tabelrijke glorie weer in Adminer te bewonderen:
Missie geslaagd. Kopje thee. Adem in, adem uit.
Nu is het tijd om de daadwerkelijke upgrade van Nextcloud uit te gaan voeren... en daarna de backup eens goed onder de loep te nemen.