Backups server-sided

Waar plaats ik server-sided backups van sites? Denk aan bestanden, maar ook aan db-backups.

Het probleem - Casussen

WordPress-plugin-update (begin 2019)

Als ik een WordPress-plugin update via een eigen script (bv. js_composer). Dan hernoem ik eerst die map naar bv. js_composer_bk_20190130_2007. Als de update is geplaatst, wil ik die map liever niet verwijderen, want te risicovol (namelijk, dat ik per ongeluk meer verwijder + dat ik 'm toch nog nodig heb). Ik kan 'm ook niet goed daar laten staan, want dan heb je opeens twee exemplaren van de plugin (echt waar!). Ik zou 'm 't liefste willen verplaatsen, maar waarheen?

Drupal Core-update (april 2019)

Onlangs is er een update gekomen die je handmatig moet doen. Dan graag eerst de hele site backuppen.

Locaties

Vereisten

• Geen persoonlijk account: Onafhankelijk van een persoonlijk account. Dus niet iets onder ~/
• Buiten bereik van Apache: Backups kunnen namelijk ook databases bevatten, en ik vind het niet prettig dat complete databases binnen bereik van Apache worden gehost. Hetzelfde geldt trouwens voor bestanden: Het vereist slechts een kleine configuratiefout om de inhoud van een serviceable map zichtbaar te maken voor bezoekers
• Vindbaar: Belangrijk dat ik dit over vijf nog terug kan vinden
• Rechten: Met lees- & schrijftoegang voor mezelf en vergelijkbare gebruikers. Da's hetzelfde als dat ik de rechten op /var/www heb aangepast
• Afspiegeling: Intuïtieve afspiegeling van wat er gearchiveerd wordt. Onder /backups zou je bv. krijgen /backups/var/www/example.com/bk-20190130/... - Dat pleit voor een kort pad
• Overzichtelijk: Liever niet combineren met een map die al voor iets anders wordt gebruikt, zoals de bestaande map /var/backups
• Dropbox: Het zou een leuke extra zijn, als dit ook nog eens een Dropbox-map zou zijn. Dat zou alleen gelden voor backups op m'n werkstation en niet op servers - Waarschijnlijk is dit criterium niet echt interessant.

Inventaris

Locaties die zoal genoemd worden:

• /var/backups - Da's een Debian-specifieke map, die ergens voor gebruikt wordt, maar kan weinig kwaad om 'm ook zelf te gebruiken
• /backups - Gemakkelijk en duidelijk
• /opt/... - Schijnt FHS-compliant te zijn, maar wat gezocht, naar mijn smaak [1]
• /srv/... - Schijnt ook FHS-compliant, maar ook wat gezocht
• /usr/local/... - Idem
• In de root van installaties: Dit is nog het meest intuïtief. Dus bv. een map /var/www/example.com/backups-dvb - Alleen is die locatie wel serviceable door Apache. UpdraftPlus voor WordPress doet zoiets met de map wp-content/updraft - Lastige keuze

Conclusies

Optie 1: /var/backups-dvb

• Meest intuïtief - Intuïtiever dan /var/backups (dat was voorheen de eerste keus)
• Ik vind het logisch dat het een map onder /var/ is (want data van variabele lengte/groote)
• Geen probleem dat ik nu als gebruiker schrijven kan op een map onder /var - Dat kon ik toch al op bv /var/www
• Vindbaarheid: Ik zou links kunnen aanmaken vanuit andere voor de hand liggende locaties naar hiero.

Optie 2: Binnen hosting-accounts

• Dit is het voorbeeld van UpdraftPlus: Dat plaatst backups ergens binnen de betreffende installatie. Ik denk dat één van de redenen is dat UpdraftPlus dat doet, is omdat het geen schrijftoegang heeft tot overige locaties
• Heel aanlokkelijk om deze oplossing te kiezen (en dan met een map zoals /var/www/example.com/backups-dvb, maar liever niet.

Concurrent backups

Op de backup-locatie zullen er meerdere backups zijn. Ik moet dus werken met aparte mappen per backup. Ik denk dat ik daarvoor mappen met timestamps in de naam zou gebruiken. Verschillende mogelijkheden:

• Timestamp zo vroeg mogelijk: Bv. /var/backups-dvb/20190401-1053 - Lastig zoeken, maar wel gemakkelijk te backuppen
• Timestamp laat maar op een vaste plek: Bv. /var/backups-dvb/example.com/20190401-1053 - Handig als je iets specifieks zoekt, maar lastiger te backuppen (bv. van server-sided naar elders), omdat je pas op een diepere laag kunt zien wat nieuw is → Ik denk dat het commando find daar wel raad mee weet
• Timestamp zo laat mogelijk: Dan hangt de locatie van de timestamp af van wat er gebackupped wordt. Je kunt dus mappen krijgen zoals
  • /var/backups-dvb/example.com/20190401-1053 - Voor een complete backup
  • /var/backups-dvb/example.com/sites/default/files/20190401-1053 - Voor een backup van alleen die map files - Te ingewikkeld!
• En-en: Waarschijnlijk zal ik verschillende structuren naast elkaar hebben: Het is te ingewikkeld om het allemaal in één structuur te willen vangen.

Conclusies:

1. Laat, maar op een vaste plek
2. En-en.

Voorbeelden

Backup ivm. Drupal Core-update

• De hele site /var/www/example.com wil ik backuppen ivm. een Drupal Core-update
• Basismap: /var/backups-dvb/example.com/20190401-1053 (de map www hoef ik voorlopig niet expliciet te vermelden: Relatief weinig data)

Bronnen

• https://unix.stackexchange.com/questions/68698/is-it-bad-dangerous-inappropriate-to-put-arbitrary-backups-in-var-backups

Appendix: Backup-locatie WordPress

Een artikel uit feb. 2019. Deze aanbeveling volg ik liever niet

Ik zoek een logische locatie op de server, voor het parkeren van backups, bv. rondom updaten van een plugin. Zie Plugins handmatig bijwerken (WordPress) voor een casus.

Aanvullende gegevens

• Ik wil de backups graag in dezelfde tree of installatie hebben als de bijbehorende WordPress-site: Da's intuïtief, plus dat het toch allemaal op dezelfde server staat → Het liefst in een map in de root van een installatie
• Uiteraard moeten backups niet worden beschouwd door WordPress als werkende onderdelen van de site (dat is het probleem met backups van plugins in de plugin-map: Die worden beschouwd als echte plugins)
• WordPress zelf, lijkt hier geen suggestie voor te doen
• UpdraftPlus gebruikt standaard map wp-content/updraft voor backups. Interessant dat dit onder wp-content is. Ik denk overigens niet dat het handig is, om deze map te gebruiken voor eigen backups
• UpdraftPlus negeert standaard mappen met de naam *backups of backups* - Handig om rekening mee te houden

Conclusie

Map in de root van een installatie, genaamd dvb-backups:

• Deze naam is om duidelijk te maken dat deze map bij mij vandaan komt. dvb-wp-backups had ook gekund, maar onnodig lang
• UpdraftPlus negeert mappen met namen als *backups en backups*, en dat komt hier mooi uit.

Zie ook

• Plugins handmatig bijwerken (WordPress)