Backups server-sided: verschil tussen versies
Naar navigatie springen
Naar zoeken springen
Optie 1:
| Regel 1: | Regel 1: | ||
| + | Waar plaats ik ''server-sided backups'' van sites? Denk aan bestanden, maar ook aan db-backups. | ||
| + | |||
== Het probleem - Casussen == | == Het probleem - Casussen == | ||
| Regel 30: | Regel 32: | ||
* In de ''root'' van installaties: Dit is nog het meest intuïtief. Dus bv. een map <code>/var/www/example.com/backups-dvb</code> - Alleen is die locatie wel serviceable door Apache. UpdraftPlus voor WordPress doet zoiets met de map <code>wp-content/updraft</code> - Lastige keuze | * In de ''root'' van installaties: Dit is nog het meest intuïtief. Dus bv. een map <code>/var/www/example.com/backups-dvb</code> - Alleen is die locatie wel serviceable door Apache. UpdraftPlus voor WordPress doet zoiets met de map <code>wp-content/updraft</code> - Lastige keuze | ||
| − | == | + | == Conclusies == |
| − | Optie 1: <code>/var/backups-dvb</code> | + | === Optie 1: <code>/var/backups-dvb</code> === |
| − | * Meest intuïtief - Intuïtiever dan <code>/var/backups</code> (dat was de | + | * Meest intuïtief - Intuïtiever dan <code>/var/backups</code> (dat was voorheen de eerste keus) |
| − | * Ik vind het logisch dat het een map onder <code>/var/</code> is (data van variabele lengte/groote) | + | * Ik vind het logisch dat het een map onder <code>/var/</code> is (want data van variabele lengte/groote) |
* Geen probleem dat ik nu als gebruiker schrijven kan op een map onder <code>/var</code> - Dat kon ik toch al op bv <code>/var/www</code> | * Geen probleem dat ik nu als gebruiker schrijven kan op een map onder <code>/var</code> - Dat kon ik toch al op bv <code>/var/www</code> | ||
* Vindbaarheid: Ik zou links kunnen aanmaken vanuit andere voor de hand liggende locaties naar hiero. | * 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 <code>/var/www/example.com/backups-dvb</code>, maar liever niet. | ||
== Bronnen == | == Bronnen == | ||
* https://unix.stackexchange.com/questions/68698/is-it-bad-dangerous-inappropriate-to-put-arbitrary-backups-in-var-backups | * https://unix.stackexchange.com/questions/68698/is-it-bad-dangerous-inappropriate-to-put-arbitrary-backups-in-var-backups | ||
Versie van 1 apr 2019 10:46
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/wwwheb aangepast - Afspiegeling: Intuïtieve afspiegeling van wat er gearchiveerd wordt. Onder
/backupszou 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- 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 mapwp-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.