[PHP/MySQL] Veilig periodiek backuppen webapp

[Roytoch]

Ik heb een PHP/MySQL webapp draaien op een DigitalOcean VPS, met ubuntu server. Een takenpakketje dat niet wereldschokkend is maar wel leuk om te bouwen, en dat inmiddels gebruikt wordt door een aantal vrienden en collega's.

Dignen als SSL/https en goed versleutelde wachtwoorden zitten er wel in, maar backuppen doe ik door in te loggen op sftp, de files te downloaden naar mijn eigen laptop, en de database te exporteren naar een .sql. Dit gaat vast ooit mis. Ik weet dat er full-fledged backup-opties zijn, maar dit is een klein project en ik wil eigenlijk niet teveel extra software op die server zetten.

Vooralsnog wil ik het oplossen door een PHPscript een mysql-export in een .sql te laten dumpen en dit samen met een copy van de public_html map naar een encryped rar file te schrijven, welke vervolgens gekopieerd wordt naar een andere server (ook van mezelf, andere host, ander datacenter). Uiteraard naar een niet publiek te openen map.

Mijn vragen zijn vooral:

• Is dit enigzins logisch of volledig stupide?
• Zit er een obvious flaw in die ik niet zie?
• Zijn er betere manieren/veiliger manieren?

[EricBruggema]

Goed idee hoor, en qua tijd kun je voor een Nederlandse site het beste tijd tussen 3-6 uur 's morgens uitkiezen om je DB te exporteren. Echter als je daar de mogelijkheid voor hebt kun je het beste alleen nieuwe data 'exporteren'. Bv als je een create/update timestamp heb, bewaar de oude timestamp en exporteer alleen maar de 'nieuwe' data.. scheelt bergen met tijd.

Ik zou zelf voor een kleine api gaan, die je met wachtwoord beveiligd. Je andere server kan dan met deze api connecten en je database uitlezen (en ontvangen, opslaan, etc).

Oh en waarom zou je al je scripts continue kopieren? qua public_html, ik zou deze dan ook doorlopen op 'nieuwere' bestanden dan de laatste keer dat je deze backup hebt gedraaid.

Wel leuk idee trouwens, zou er bijna een script/api voor gaan schrijven

[ Voor 19% gewijzigd door EricBruggema op 26-08-2015 09:43 ]

[mbarie]

Je kan toch een periodieke database dump doen en deze+de app middels rsync binnenhalen/versturen naar je backup-locatie? Maak wat SSH keys aan en je kan alles veilig via SSH overzetten.

[ Voor 24% gewijzigd door mbarie op 26-08-2015 09:52 ]

[TheNephilim]

Waarom heb je niet gekozen voor de backup optie die DigitalOcean biedt? Als je toch niet afzonderlijke delen willen backuppen, kun je net zo goed de hele VPS backuppen. Via het controlpanel van DigitalOcean kun je deze ook gemakkelijk herstellen.

[gekkie]

De potentiele "obvious" flaw is dat je er wellicht niet op attent wordt gemaakt als een en ander faalt.
Je zal niet de eerste zijn die in de veronderstelling is dat er backups gemaakt worden terwijl er ergens iets is veranderd waardoor ze al enige tijd niet meer werken.
Toch met enige regelmaat checken / testen dus.

[BLACKfm]

gekkie schreef op woensdag 26 augustus 2015 @ 10:14:
De potentiele "obvious" flaw is dat je er wellicht niet op attent wordt gemaakt als een en ander faalt.
Je zal niet de eerste zijn die in de veronderstelling is dat er backups gemaakt worden terwijl er ergens iets is veranderd waardoor ze al enige tijd niet meer werken.
Toch met enige regelmaat checken / testen dus.

Laatste record/timestamp wel ergens publiekelijk wegschrijven en in een controlepaneel van de site een tooltipje of opmerkingen veld met de mededeling dat de laatste backup datum X heeft met de waarde Y. Als dat van een paar dagen oud is kan het zijn dat de backup niet meer werkt.

[gekkie]

BLACKfm schreef op woensdag 26 augustus 2015 @ 15:47:
[...]
Laatste record/timestamp wel ergens publiekelijk wegschrijven en in een controlepaneel van de site een tooltipje of opmerkingen veld met de mededeling dat de laatste backup datum X heeft met de waarde Y. Als dat van een paar dagen oud is kan het zijn dat de backup niet meer werkt.

Doe dan op z'n minst ook de filesize erbij

[8088]

Roytoch schreef op dinsdag 25 augustus 2015 @ 22:05:
Vooralsnog wil ik het oplossen door een PHPscript een mysql-export in een .sql te laten dumpen

Is mysqldump niet voldoende?

en dit samen met een copy van de public_html map naar een encryped rar file te schrijven

Waarom kiezen voor een propriëtair formaat als je kunt kiezen voor (bijvoorbeeld) een tar.gz versleuteld met (bijvoorbeeld) gpg?

EricBruggema schreef op woensdag 26 augustus 2015 @ 09:41:
Oh en waarom zou je al je scripts continue kopieren? qua public_html, ik zou deze dan ook doorlopen op 'nieuwere' bestanden dan de laatste keer dat je deze backup hebt gedraaid.

Dan kun je de mist in gaan als je server compromised is en iemand met de timestamps heeft zitten klooien. Sowieso lijkt het me dat tijdswinst bij het restoren prevaleert boven ruimte- en tijdsbesparing tijdens het backuppen.

TheNephilim schreef op woensdag 26 augustus 2015 @ 10:09:
Waarom heb je niet gekozen voor de backup optie die DigitalOcean biedt?

Ik denk hierom:

Unfortunately you are unable to store a snapshot or backup outside of our environment.

Handig voor erbij, maar geen volwaardige backup.

Wat het loggen betreft: rsync kan met --stats leuke stats genereren en voor de output van je cronjobs kun je een e-mailadres instellen.

Backups zijn best belangrijk, dus ik zou het hele proces zo simpel mogelijk houden.

[Gerco]

Vooralsnog wil ik het oplossen door een PHPscript een mysql-export in een .sql te laten dumpen en dit samen met een copy van de public_html map naar een encryped rar file te schrijven, welke vervolgens gekopieerd wordt naar een andere server (ook van mezelf, andere host, ander datacenter).

Dat is ongeveer wat ik ook doe. Elke zoveel tijd (dag/week verschilt per server/app) draait er een cron script wat de files in een .tar.gz steekt en upload naar Amazon S3. Vervolgens krijg ik een emailtje dat de backup is geslaagd. Als ik die email dus een dag niet krijg weet ik dat er iets mis is.

Er zijn natuurlijk betere systemen, maar dit werkt al jaren prima. Amazon S3 is niet de allergoedkoopste host maar het is ook niet heel duur. Ik heb een paar honderd GB daar staan en betaal iets van $0.03/GB/maand (standaard US East S3 pricing met reduced reduncandy, weet niet precies hoeveel het is).

Wat ik wel kan aanraden is om het niet in Glacier te zetten. Het lijkt goedkoop met slechts $0.01/GB/maand, maar restoren kan wel eens heel duur uitpakken (Google even rond). Als je ook je backups regelmatig ververst dan telt dat als een delete en reupload in Glacier en dat kost ook weer extra. Afhankelijk van hoeveel files je wilt opslaan kunnen de kosten bij Glacier behoorlijk uit de hand lopen, ook al lijkt het in eerste instantie heel goedkoop.

[ Voor 12% gewijzigd door Gerco op 26-08-2015 17:31 ]

[Roytoch]

Iedereen, bedankt voor alle reacties! De in digitalocean ingebouwde backup vind ik zelf inderdaad niet voldoende omdat het er vanuit gaat dat de fout nooit bij digitalocean ligt. Ik ga het een tijdje proberen met mysqldump + targz (dank voor beide tips) via SSH naar een andere server.

Overigens is het hele webappje gezipt 917 kilobyte - ik probeer door CSS/icon fonts het aantal afbeeldingen laag te houden - dus qua bandbreedte is er niet heel veel aan de hand per se.

[d91]

Ik heb zelf een Bash-scriptje gemaakt dat een MySQL-dump maakt, deze zipt en naar mijn e-mailadres stuurt.

code:

#!/bin/bash

DB_BACKUP="/backups/mysql_backup/`date +%Y-%m-%d`"
DB_USER="username"
DB_PASS="password"
MAIL_SUBJECT="MySQL backup `date +%Y-%m-%d`"
MAIL_BODY="Here is your MySQL backup! `date +%Y-%m-%d`"
TO_EMAIL="[e-mail]"

mysqldump --all-databases --user=$DB_USER --password=$DB_PASS > "$DB_BACKUP.sql"

zip -r "$DB_BACKUP.zip" "$DB_BACKUP.sql"
rm "$DB_BACKUP.sql"

uuencode "$DB_BACKUP.zip" "backup.zip" | mail -s "$MAIL_SUBJECT" -t $TO_EMAIL

Dit script heb ik vervolgens aan de cronjobs van mijn Ubuntu Server VPS toegevoegd. En ja, er zijn wat beveiligingsrisico's aan verbonden, omdat je natuurlijk je username en password in je script gebruikt.