Onderwerp: DirectAdmin rsync script

Waarom wordt er door ons bij DA niet feature request neergelegd voor een incrementele backup oplossing. Ik denk dat wij genoeg licenties bij elkaar hebben om dit van hen te eisen.

Zou fijn zijn als DA dat inderdaad wat netter oplost/aanbiedt. Mijn eerder aangedragen oplossing werkt echter prima en is incrementeel (en met versioning). Maar het kan nog beter:

http://www.directadmin.com/features.php?id=951

Je kan na het maken van de admin-backups een script laten draaien zodat hij de tar.gz weer uitpakt (bijv. gunzip $file && tar -xf $file). Dan daarna rsync of rdiff er overheen.

Helaas lost dat het probleem van de load niet op. Misschien kan de compressie uit of zo:

http://www.directadmin.com/features.php?id=792

Het in eerste instantie inpakken van de files is een beetje onhandig van DA maar staat in de binairies en kan niet uitgezet worden. Maar zoals al eerder gezegd kan je ook één keer per week de volledige backups downloaden (zoals hierboven aangegeven dus ook incrementeel) en de overige zes dagen gewoon systembackup + rsync/rdiff. Dat scheelt veel load.

Wij hebben het probleem op de meeste servers helemaal niet meer omdat wij met virtualisatie de hele VPS waar DA in draait incrementeel en met versioning kunnen backuppen (LVM2 snapsots + Rdiff). Dat is werkelijk ideaal.

Mocht iemand er niet uitkomen met het schrijven van een bashscriptje kan je mij altijd PMen.

Oorspronkelijk geplaatst door rimote

Overigens is het naar mijn mening beter om te pushen naar een backupserver (aparte backup VPS per productie VPS) dan te pullen vanaf de backupserver. Pullen vanaf een backupserver betekent dat deze toegang heeft tot een productiemachine. Wordt de backup gekraakt, hebben ze vaak toegang tot meerdere productiemachines.

Je kan de key van de backup server limiteren, maw ondanks hij binnen de root pool valt kun je aangeven dat enkel dat rsync commando uitgevoerd mag worden en alle andere commando's niet. Dit is netjes op te zetten binnen je authorized keys.

da trapt toch gewoon 'tar' aan bij het maken van een backup? Er is toch niemand die je tegenhoudt om een 'tar' shellscriptje te maken dat de parameters in een rsync gooit?
Gewoon de originele tar renamen.

Oorspronkelijk geplaatst door systemdeveloper

da trapt toch gewoon 'tar' aan bij het maken van een backup? Er is toch niemand die je tegenhoudt om een 'tar' shellscriptje te maken dat de parameters in een rsync gooit?
Gewoon de originele tar renamen.

zal wel aan mij liggen, maar ik snap je niet

Oorspronkelijk geplaatst door Mikey

zal wel aan mij liggen, maar ik snap je niet

Als je de da backupfunktie voor je klanten in stand wilt houden
DA trapt vanuit zijn code gewoon tar aan. Als je de tar executable vervangt door een scriptje dat de parameters gebruikt om een rsync regeltje aan te trappen, dan ben je van de hoge load af, kun je de da backup/restore funktie gewoon nog gebruiken en kun je de backups via ssh ook automatisch op een backupbak mikken (incl. rotating als je wilt).

Ik kan niet voor anderen spreken, maar een individuele klanten backup verdwijnt qua load gewoon op de grote IO hoop, daar merken wij en de klanten niets van (centrale storage).

En ik denk dat je beter een feature request aan kan vragen dan de tar bin veranderen. Gebruik hem zelf te vaak om hem te moeten hernoemen

Oorspronkelijk geplaatst door Mikey

Ik kan niet voor anderen spreken, maar een individuele klanten backup verdwijnt qua load gewoon op de grote IO hoop, daar merken wij en de klanten niets van (centrale storage).

En ik denk dat je beter een feature request aan kan vragen dan de tar bin veranderen. Gebruik hem zelf te vaak om hem te moeten hernoemen

Het gaat ook niet om jouw situatie maar om TS zijn situatie.
Ikzelf heb tar maar zelden nodig op een da server. Hooguit bij de updates maar dan switch je even de tar bin terug.
Maar ik heb wel klanten die 200-300GB websites hebben... als je nu op da moet gaan wachten word je ook niet vrolijk hoor. Centrale storage of niet...
Maar uiteraard kun je ook een featurerequest indienen en dat afwachten.

Op de betreffende servers staat DA backup voor alle klanten disabled, die kunnen tegenwoordig hun backup downloaden vanuit het klantenpaneel.

Voor wie de user backup functie in tact wil laten met uitzondering van het tijdspad dat er admin backups gemaakt worden:

Code:

/etc/cron.d/directadmin_cron
59 2 *  * * diradmin /usr/bin/perl -pi -e 's/skip_domains_in_backups=0/skip_domains_in_backups=1/g' /usr/local/directadmin/conf/directadmin.conf

/usr/local/directadmin/scripts/custom/user_backup_post.sh

#!/bin/bash
LASTUSER=$(/bin/ls /usr/local/directadmin/data/users/ |/usr/bin/tail -n 1)
if [ "${username}" = "${LASTUSER}" ];
then
        /usr/bin/perl -pi -e 's/skip_domains_in_backups=1/skip_domains_in_backups=0/g' /usr/local/directadmin/conf/directadmin.conf
fi

Zorg dat de crontab 1 minuut eerder loopt dan je admin backup, user_backup_post.sh past na de laatste user de conf value in directadmin.conf weer aan.

Interessant topic...

Zelf zat ik te denken naast incremental backups gemaakt met rysnc gebruik te maken van een image van een volledige schone installatie van OS, DA en overige software die ik nu test/gebruik bij nieuwe installaties van servers middels een Image Server.

Je zou bij een volledige restore (en geen live spare server hebben staan) relatief snel een nieuwe server kunnen inrichten, hierna overschrijf je de server configuratie en gebruikers bestanden/instellingen van de rysnc backup.

Ik ben zelf nog aan het testen van gebruik van verschillende imaging en cloning software en de mogelijkheden daarvan.
Ik loop nu nog steeds tegen he probleem aan dat het clonen vrij lang duurt en veel dataverkeer verstookt.
Echter ik ben nu ff bezig met PING en deze zou na een 1e clone gemaakt te hebben alleen nog maar gewijzigde data koppieren, dit zou mischien ook een mogelijke oplossing kunnen zijn?
Of gebruik beide methodes, resync elke dag en clonen eens in de week..

Nou ja goed, ik weet het ook niet precies ben er nog mee bezig...
Ondertussen blijf ik het hier maar volgen..

Een server restore doen wij gewoon vanaf 0. Schone OS, schone DA, dan alle tools en stuff erover en daarna zend optimizer/ioncube/php-imagick/php-imap etc etc. Maar meestal hebben we een server spare draaien tot en met de schone DA.

Daarna admin accountje ff instellen met de ip's en nameservers die gebruikt werden en de admin back-ups van alle users terugpompen.

We doen eigenlijk alles enkel met admin back-ups per user. Ook omdat je dan een stukje extra service kan verlenen als een klant een back-up wil van x dagen geleden. We hebben nu altijd een backup van gisteren, eergisteren, afgelopen vrijdag en vorige vrijdag en in luxere gevallen gewoon altijd 7 dagen retentie. Deze zetten we op aanvraag gratis terug, mits het in 1x mag zonder behoud van nieuwste versie van de database enzo.

Al onze servers beginnen om 1u met admin backups en zijn voor 5u klaar. Dit wordt allemaal naar 2 back-up servers gestuurd die elke paar dagen weer ge-r-synct worden naar elders buiten het DC.

We zijn wel op zoek naar een nieuwe oplossing om de back-ups netter te spreiden over de back-up servers en dit zo slim mogelijk te doen. Ik vind het wel jammer dat je met de DirectAdmin back-up tools geen enkele vorm van ontdubbelen kan instellen. Zo had wat mij betreft de back-ups wel geskipt mogen worden als bijvoorbeeld de databases en/of de public_html's onveranderd zijn.

(Bovenstaande geldt trouwens alleen voor shared hosting zonder extra back-up abonnement)

Oorspronkelijk geplaatst door Keizer

We doen eigenlijk alles enkel met admin back-ups per user. Ook omdat je dan een stukje extra service kan verlenen als een klant een back-up wil van x dagen geleden. We hebben nu altijd een backup van gisteren, eergisteren, afgelopen vrijdag en vorige vrijdag en in luxere gevallen gewoon altijd 7 dagen retentie. Deze zetten we op aanvraag gratis terug, mits het in 1x mag zonder behoud van nieuwste versie van de database enzo.

Als klanten met grote files, vele databases zitten dan loopt het al gouw op naar de vroege uurtjes en is je disk & netwerk niet zo tevreden.

Een rsync copy, bacula copy of enige andere backup mogelijkheid hebben vaak de mogelijkheid file per file te restoren. Hierop (bij bacula) hebben we een template gemaakt waarmee we dus gewoon user xxx kunnen restoren en het script doet de rest. Deze gaat dan alles in de files bij elkaar sprokkelen (wat de DA backup ook doet). Op die manier kun je dan snel ook een hele server restoren naar de laatste status, dus inclusief php settings, zend, pear, ...

Voordeel van zo'n constructie is dat je mooi incrementeel kan backupen en dat het veilig gebeurd (pull in plaats van push !). Backups kan je dan regelen op een goed tijdstip voor de klant en voor jouw backup hardware. Niet alles in één keer starten, maar een planning maken met wisselende full-backups

Ik mag er niet aan denken als jouw servers gehackt worden door een kid dat graag alles delete(uit ververling), deze neemt dan gelijk ook de backup server mee!

Oorspronkelijk geplaatst door Tim.Bracquez

Als klanten met grote files, vele databases zitten dan loopt het al gouw op naar de vroege uurtjes en is je disk & netwerk niet zo tevreden.

Zoals ik al aangaf zijn ze allemaal netjes klaar voor 5 uur (soms een uitloopje tot half 6), dus daar zit geen probleem in. Om 5 uur starten we een tweede batch dedicated klanten die half 6-6 uur klaar zijn. Daarbij gebeurt het pompen over een extra intern gbit netwerk en kan de HDD de minieme aantal bezoekers/bots rond dat tijdstip prima aan naast dataskq

Oorspronkelijk geplaatst door Tim.Bracquez

Ik mag er niet aan denken als jouw servers gehackt worden door een kid dat graag alles delete(uit ververling), deze neemt dan gelijk ook de backup server mee!

Als de kid het lukt om op onze backupserver in te loggen met de (versleutelde?) usergegevens die hij vindt op de gehackte server én hij is zo slim om via de gehackte server in te loggen op de back-upserver en dit lukt hem allemaal binnen de tijd dat wij op de hoogte zijn van de hack, dan zou hij inderdaad de meest recente back-ups kunnen verwijderen. Gelukkig hebben we dan altijd nog een full back-up van een dag of 2-3 oud, dat ligt even aan het tijdstip van de hack.

Maar ik wist eigenlijk niet dat het zo makkelijk was om de login credentials van de ftp users van de back-crons te achterhalen. Elke user heeft wel een eigen sterk wachtwoord van 8 karakters, maakt dat wat uit? Een eenvoudig oplossing is dan om de inkomende back-ups te verplaatsen naar een ander plekje op de HDD, zodat de kid met de gelekte login credentials bot vangt? Of zie ik dat verkeerd?

Nogmaals ik ben hier om te leren en wil andere opties die jij noemt ook graag een keer bekijken.

Oorspronkelijk geplaatst door Keizer

Een server restore doen wij gewoon vanaf 0. Schone OS, schone DA, dan alle tools en stuff erover en daarna zend optimizer/ioncube/php-imagick/php-imap etc etc. Maar meestal hebben we een server spare draaien tot en met de schone DA.

Ik denk dat voor sommige (in ieder geval voor ons) 1 van de belangrijke punten van een betere backup/restore is de snelheid waarmee een restore terug gezet kan worden.

Ook wij gebruiken de system backups bij een restore omdat dit prettiger werkt en naar mijn idee ook sneller dan de user backups en je kan dagen terug wanneer een klant een backup uit het verleden wilt.

Voorheen (en nog steeds) gebruiken wij onze update script waarmee wij alle servers middels PSSH kunnen updaten ook voor nieuwe installaties van configuratie en overige software op nieuwe servers
Install OS --> run script --> optie: install_config_all en server is klaar voor gebruik.

Echter ik zit eigenlijk al een tijdje te denken dus aan images, OS, software en config alles in 1 image, scheelt ons toch weer een half uur denk ik.

Je zou vervolgens op in de image een restore functie kunnen inbouwen dat je na restore kan aanroepen /scripts/restore_server.sh
vervolgens laat je alles terug syncen van de laatst complete backup.

Maar, ik wil toch verder kijken naar de clone methode, waneer de clone software in staat is alleen gewijzigde bestanden unzipped naar de image server te sturen en die daar aan de zip toevoegd of wijzigd kan het maken van een dagelijkse backup kwa tijd en dataverkeer ook worden terug gebracht.
Restoren van een server is dan helemaal kinderspel en binnen 30 minuten a 2 uur gepiept.

Enigste vereisten zijn wel veel en grote harddisks extra, maar dat zijn eenmalige uitgaves.
Indien gewenst draai je naast deze clone methode ook nog een system backup of user backup, altijd handig..

Ik mag er niet aan denken als jouw servers gehackt worden door een kid dat graag alles delete(uit ververling), deze neemt dan gelijk ook de backup server mee!

Is ons in het verleden gebeurd doordat wij indd een scriptje draaide waar de het wachtwoord in plain txt van de eerste backup server in stond vermeld.
Sindsdien wordt onze backup server 1x in de week geback-upt

Edit: als je alles hier terug leest vraag je je af:
Waarom geen virtuele servers, probleem opgelost...
(we zijn er mee bezig..)

Edit 2:
Ik zie zojuist dat PSSH ook Parallel rsync ondersteund.
Dit zou veel tijd en data kunnen schelen, ik weet wat er precies wel/niet mogelijk is, kijk daar morgen ofzo wel eens naar, voor nu even belangrijkere taken te doen..
http://code.google.com/p/parallel-ssh/