Backups server-sided

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen

Het probleem

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?

Locaties

Vereisten

  • Onafhankelijk van een persoonlijk account. Dus niet iets onder ~/
  • Bij voorkeur: Buiten de boom van servable content. Dus buiten bereik van Apache
  • Vindbaar: Gemakkelijk om terug te vinden, over bv. 5 jaar
  • Met lees- & schrijftoegang voor mezelf en vergelijkbare gebruikers. Da's hetzelfde als dat ik de rechten op /var/www heb aangepast
  • 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

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 - Erg gemakkelijk en duidelijk. Eigenlijk
  • /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.

Conclusie

/var/backups

  • Meest intuïtief
  • Ik vind het logisch dat het een map onder /var/ is (data van variabele lengte/groote)
  • Kan geen kwaad.

Bronnen