Onderwerp: DirectAdmin gebruikers : hoe maak jij jouw backup?

Oorspronkelijk geplaatst door IT-worX

Er moet in een account maar één mailtje bijkomen en alles gaat terug een re-sync krijgen.

De clou van rsync is juist dat alleen wijzigingen doorgevoerd worden. Dat kan ook bij de .tar.gz backups van DA, check mijn post op de vorige pagina.

@The-Boss Dusdanig grote websites hosten wij eigenlijk niet op ons shared hosting platform (dit soort sites gaan gauw enorm belasten), wel op virtuele servers. Het kost wel veel bandbreedte, maar als je dat in overvloed hebt, is dat ook geen probleem.

Wij maken gebruik van Continuous Data Protection® - Enterprise Edition. Perfect pakket voor backups

Dan doel je op Idera (r1soft) neem ik aan =)

Hier gebruiken wij gewoon de backup functie van DirectAdmin zelf, alleen met een aangepast ftp_upload.php script zodat dit via NcFTP draait. Vervolgens op de NAS per server een FTP account aangemaakt met de mappen dag1 t/m dag7 en bij sommige servers ook week1 t/m 4 (of nog meer), dan vervolgens per dag een cronjob ingesteld via DirectAdmin (de admin backup).

Draait prima, en backups terugplaatsen is een fluitje van een cent.

Dat heb je goed.. Prima software

Inmiddels is het hier met wat hulp ook opgelost.
De backup gebeurd nu elke dag onsite (retentie van 7 dagen) en op de nacht van zondag op maandag gebeurd er een rsync met een offsite server (in datacenter) van de backup van zaterdagochtend. Lijkt mij voor persoonlijke sites toch al goed zo

Oorspronkelijk geplaatst door IT-worX

Inmiddels is het hier met wat hulp ook opgelost.
De backup gebeurd nu elke dag onsite (retentie van 7 dagen) en op de nacht van zondag op maandag gebeurd er een rsync met een offsite server (in datacenter) van de backup van zaterdagochtend. Lijkt mij voor persoonlijke sites toch al goed zo

Misschien nog een tip in geval van rsyncs (als je het al niet doet). Maak vóór de dagelijkse rsync een mysqldump van je databases en rsync die mee. Bij DA backups gebeurd dat al uiteraard, maar als je die niet gebruikt en alleen een rsync doet, dan heb je alleen de binaire database bestanden en die zijn zelfden consistent.

Systemdeveloper:
Dagelijks gebeurd de backup via de standaard admin backup van DA. Deze zal alle usernames in een tarball zetten en via FTP naar een andere server gooien (in dit geval mijn nas). De rsync die wekelijks gebeurd is gewoon een pull van de externe server (in een datacenter) van alles wat er op de nas staat in het mapje "zaterdag". Dus alle tarballs van die dag.

Wij maken elke nacht backups met behulp van rdiff-backup. Dit doen we met de pull methode om te voorkomen dat alle machines tegelijk naar de backupserver gaan pompen. De backupserver beslist wanneer een server aan de beurt is.

Rdiff maakt netjes incrementele backups van voorgedefinieerde mappen die nodig zijn om DA snel te kunnen herstellen na een crash, dus geen overbodige mappen, grote backupfiles etc. Die increments worden bewaard op het aantal dagen dat wordt aangegeven in de config (retentie) en daarna vanzelf verwijderd. Eigenlijk een beetje het rsync idee.

Werkt al jaren prima.

Een ander voordeel van een pull ten opzichte van een push is de kwestbaarheid. Als je met een push werkt en de server wordt gehackt kan deze hacker ook de backups verwijderen. (Of je moet deze weer veiligstellen op de backupserver nadat alle bestanden gesynchroniseerd zijn)

Momenteel ziet mijn backup strategie er als volgt uit.

DA maakt userlevel backups > /home/admin/
Mysql dump > /backup

rsync pull vanaf de backupserver op /backup en /home (en de DA configuratie directories). Op deze server word vervolgens nog een retentie opgebouwd, 7 dagen + maandelijkse backups (6 maanden).

Kost wel een bult aan backup ruimte want ja alles word dubbel gebackupd. Tot voorkort was dat niet zo'n probleem maar de ruimte op de backupserver begint zo langzamerhand wel op te raken dus ik zal deze strategie wel iets gaan aanpassen in de komende tijd. Maar als ruimte geen issue is vind ik het persoonlijk erg fijn om snel losse files terug op verzoek van klanten en om bij calamiteiten gebruik te kunnen maken van de DA backups.

Wij hebben het als volgt opgelost:

Per rack 1 (of meer) eenvoudige freebsd backupserver(s) met raid 5 en zfs filessystem.
Per server/vps maken we op de backupserver automatich 2 zfs filesystems, 1 voor een rsync van de losse bestanden en 1 voor snapshots van vpssen.
Via een zelf ontwikkeld systeem schedulen we de backups waarbij snapshots 1 keer op de zoveel tijd gebeuren (sqeuentieel) en rsyncs met x aantal tegelijk kunnen draaien.
Elke server kan dan eventueel nog zijn eigen (rsync) backup directory mounten, de master vs nodes kunnen de snapshot directories mounten.
Met name het zfs-filesystem-per-server biedt veel mogelijkeden (wel/geen compressie, rechten, dedups, quotas, e.d.) en beveiliging terwijl het systeem flexibel genoeg is om volledige sapshots terug te plaatsn of slechts een enkel bestandje.
Voor de shared hosting servers hebben we overigens ook nog de da backups aan staan zodat we op nivo van recovery, userlevel en filelevel kunnen restoren.

Het klinkt misschien ingewikkeld, maar dat valt reuze mee en het draait al jaren naar tevredenheid.

Wij hebben een speciale backup server (buiten het netwerk) staan waarop DA automatisch alles in de nacht naar back-ups maakt netjes verdeeld in mappen via FTP. Verder maken we op de server zelf nog voor de belangrijkste accounts een backup zodat deze ook sneller bij de hand is mocht het nodig zijn.

Backup server is verder alleen intern (via ons netwerk) te bereiken.