PDA

Bekijk Volledige Versie : DirectAdmin gebruikers : hoe maak jij jouw backup?



IT-worX
02/01/13, 18:35
Eigenlijk zegt de titel reeds alles : da-gebruikers aller landen, hoe maak jij jouw backup?

Reden waarom ik het vraag : hier is onlangs een backup grondig fout gelopen, uiteraard net op het moment dat je deze nodig hebt. Daardoor zou ik graag werken met elke dag een incredimental en elke week een full backup.

De setup hier:
- Eén server die met XenServer is verdeelt in een aantal vps'jes, waarvan ééntje met DA
- Eén server (voip) die nog genoeg hdd ruimte heeft om de backups op te zetten (zelfde locatie)
- Eén server op andere locatie, bedoeld om de backups te bevatten.

De server met DA op en de VoIP server staan hier gewoon thuis en zijn dmv een gigabit switch verbonden met elkaar (beiden hebben een gigabit poort). De server in het datacenter is ook verbonden met gigabit, maar hier is uiteraard de upload van mijn lijntje thuis de spelbreker (10mbit up, 16mbit down).

Hoe zouden jullie een backup maken met deze opstelling?

CT0
02/01/13, 19:03
Als je het thuis hebt draaien dan zullen het niet heel veel klanten zijn en dus ook niet heel veel data, en dan zou ik het bij de native directadmin backups houden. Die gewoon dagelijks offsite laten FTP-en.

Niet het meest efficient, maar wel betrouwbaar.

IT-worX
02/01/13, 19:07
Klanten kan je het niet echt noemen, zijn meer vrienden en verenigingen waarbij ik betrokken ben. Gaat alles samen toch wel over een pakje GB's dat een backup krijgen. Hele fotoalbums etc. Dus je zit snel aan rond de 50GB.

vDong
02/01/13, 20:29
Ik maak filebased backups (met een backuppakket) naar een ander DC. Tevens maak ik dagelijks mysql backups van de losse databases, deze worden als files ook weer gebackupped. Met deze methode is de data 7 dagen per file/directory (of compleet) te restoren en databases zelf 2x7 dagen.
Ik zou ten alle tijden offsite backups maken.

IT-worX
02/01/13, 20:33
vDong : dat is ook wat ik zou wensen, maar ik vrees dat mijn uploadcapaciteit dan te kort zou schieten. Vorige keer was ik meer dan 24u (ik gok alles samen 36u) bezig met één backup, continue aan 10mbit. Vandaar dat ik wekelijks de backup zou sturen naar een externe backupserver en dit voor de rest "binnenshuis" houden. De wekelijkse backup kan ik limiten aan bvb 5mbit zodat ik nog wat capaciteit over heb voor websites, mail etc.

Ik begrijp dat jullie liever offsite backups wensen, gezien jullie professionele activiteiten.

systemdeveloper
02/01/13, 20:58
Als je de bakken thuis hebt staan dan koop 1-2 externe disks en backup gewoon lokaal (met een retentie van x dagen).
Vervolgens rsync je de boel vanaf de externe disk naar het dc. Zal alleen de eerste keer lang duren, maar daarna worden alleen de wijzigingen overgepompt.

IT-worX
02/01/13, 21:07
systemdeveloper : Dit is inderdaad wat ik zat te denken (ipv externe disk wel naar de hdd van mijn voip bak, daar er daar meer dan plek genoeg nog op is). Waarbij dan de bijkomende vraag komt : hoe kan je zorgen dat de backups een retentie hebben van pakweg een week? Hoe kan je DA dus op die manier een backup laten maken? Je kan uiteraard een backup maken via DA tools zelf maar is deze manier aan te raden?

Het idee is dus telkens het volgende in te stellen bij de system backup:
Step 1 = who = All Users
Step 2 = When = Day of Week x
Step 3 = Where = ftp'en naar mijn voip server
Step 4 = What = All data

Daar deze backup dus 7 keer aanmaken : telkens step 2 veranderen naar de dag (maandag/dinsdag/...) en step 3 aanpassen naar het correcte path op de server (/home/backup/maandag, /home/backup/dinsdag/...).

En dan via rsync de map /home/backup/zondag telkens laten rsyncen met de backupserver in het datacenter?

Zoiets?

Keizer
02/01/13, 21:30
Jep, ik voorzie ook elke server van 7 cronjobs, of 10 (6x wekelijks en 4x maandelijks).

IT-worX
02/01/13, 21:33
Keizer : bedankt voor jouw bijdrage. De lokale backup kan ik dus alvast instellen, en dan eens kijken naar die rsync.
Andere tips zijn altijd welkom!

SF-Jeroen
02/01/13, 21:42
Je kan hier gewoon een compleet goed werkend script downloaden wat met incremental (= alleen wijzigingen t.o.v. eerdere backup) backups en rsync werkt: http://www.cloudvps.nl/blog/nieuwe-versie-xls-backup-script

Arieh
02/01/13, 21:47
Je kunt de DA backups ook rsyncable maken, heb hier een tijdje terug op DA forums over gehad: http://www.directadmin.com/forum/showthread.php?t=43420

Er staat in de opening post een script die met rsync werkt en de backup elke dag verplaatst naar een dag hoger, en rsync gebruikt dan de vorige dag als bron.

Om de .tar.gz backups rsyncable te maken:



1) Edit:
/etc/cron.d/directadmin_cron

2) Make the dataskq call look like:
Code:

* * * * * root GZIP="--rsyncable" /usr/local/directadmin/dataskq

and restart crond.


Ik heb er destijds vanaf gezien omdat het sneller is met 100Mbit full te pompen, maar gezien je maar 10 hebt zou dit een oplossing kunnen zijn.

Andere opties:
- Maak DA backup zonder domain directory, rsync de domain dir apart
- Maak gewone DA backup, maar plaats grote mappen (fotos bijv) naar een dir die geexclude worden bij DA backups: http://help.directadmin.com/item.php?id=281, en rsync die dir weer apart

systemdeveloper
02/01/13, 21:54
In princips hoef je geen da backups te maken. Is ook een beetje 'ingewikkelder' in combinatie met rsync omdat je namelijk alleen de wijzigingen wilt versturen en niet telkens een hele da backup van een gebruiker.
Je kunt de gzip's van DA overigens wel resyncable maken, maar dat spaart je niks aan resources tijdens het maken van de backup, alleen wat traffic. Zonder de da backup gaat het het snelste :)
Daarnaast kun je ook nog 1 keer een snapshot van je vpssen maken en die even bij de hand houden lokaal (exporteren naar een ander bakkie dus). Dat spaart je veel setupwerk als een vps eens onherstelbaar raakt.

Edit: Arieh was me net voor :)

IT-worX
02/01/13, 22:09
Dit script kende ik niet (enkel dabackup.com). Zijn er nog mensen die dit gebruiken? Is het wat up-to-date?

Tim.Bracquez
02/01/13, 23:10
Maak dagelijks een backup met directadmin van de config files en dan met rsync of bacula een incremental backup.

Dan kan je
- bare metal restore
- restore per user
- restore per file

t.bloo
02/01/13, 23:58
Die directadmin backups zijn erg handig om te hebben voor als je eens wat snel compleet terug moet zetten. Al veel gebruikt op verzoek van klanten. Ze vragen alleen nogal wat resources en daarom maak ik ze maar eens per week.

Ik doe het zelf zo:
- iedere dag een mysql dump naar ...backups/mysql
- iedere week een directadmin dump naar ...backups/directadmin
- iedere nacht een rsync van de hele server naar een backupserver
- iedere nacht een rotation script op basis van hardlinks
- paar keer per week een rsync van de backup naar een tweede locatie

Hiermee heb je iedere dag een goede backup van alle files, emails en databases. Met de rotation worden heel ruimte-effiicent backups van 6 dagen, 3 weken en meerdere maanden bewaard. Echt een aanrader. Je hebt iedere week wel even wat dataverkeer voor je dabackups, maar rsync kun je heel fijn bandwidth limiten.

Het is effe te veel werk om het helemaal hier neer te zetten, daarom hier alleen de belangrijkste componenten. Complete scripts gratis bij een backup account :)

de basis rsync code


rsync \
--archive --compress --inplace \
--delete --delete-excluded \
--bwlimit=$(($KBIT / 8)) \
--max-size=$MAXSIZE"M" \
/ $USER@$SERVER:last \
--filter="merge filterfile" \
--stats --human-readable --progress


een sample filterfile, voeg toe wat regelmatig verandert maar zinloos is om te backuppen


- /tmp
- /dev
- /proc
- /sys
- /srv
- /mnt
- /opt
- /bin
- /sbin
- /lost+found
- /selinux
- /cdrom
- /media
- /home/tmp
- /var/cache
- aquota.user
- aquota.group
- *nobackup/


de basis van het hardlink script


DATE=`date "+%Y-%m-%d"`
LAST=`ls $DESTDIR/ -1 --ignore=last|tail -1`
ionice -c3 cp -al $DESTDIR/$LAST $DESTDIR/$DATE
rm -f $DESTDIR/last; ln -s $DATE $DESTDIR/last


rotation


DATE=`date "+%Y-%m-%d"`
today=`date +%s --date=$DATE`
day=$((24 * 60 * 60))
for dir in `ls $DESTDIR/ --ignore=last`; do
date=`date +%s --date=$dir`
if [ $? = 1 ]; then continue; fi
keep=0
# skip if older than some months
if [ $date -gt $(($today - $MONTHS*31*$day)) ]; then
# keep if first day of month
if [ `date +%d --date=$dir` -eq 1 ]; then
keep=1
else
# skip if older than some weeks
if [ $date -gt $(($today - $WEEKS*7*$day)) ]; then
# keep if sunday
if [ `date +%u --date=$dir` -eq 7 ]; then
keep=1
else
# keep if younger than some days
if [ $date -gt $(($today - $DAYS*$day)) ]; then
keep=1
fi
fi
fi
fi
fi
# remove folders not to keep
if [ $keep -eq 0 ]; then
chmod -R +rwx $DESTDIR/$dir
ionice -c3 rm $DESTDIR/$dir -rf
sleep 1
fi
done

IT-worX
03/01/13, 20:41
Voorlopig ben ik even bezig met het standaard backupscript. Echter blijk ik hier tegen permissies aan te lopen...

Primaire bedoeling : elke dag een backup maken (compleet) van alles. Deze backups per gebruiker naar een andere server zetten (intern dataverkeer, dus maakt niet zoveel uit).

[root@v01 ~]# du -sh /home
43G /home

Vandaag voor die 43GB een backup gestart naar de voip-server (die heeft nog wat plaats over). Gestart om 16:35:00 en de laatste gebruiker om 18:30:30. De volledige backup van alle gebruikers duurt dus +/- 2u.

Nu, zie ik dat er overal de volgende foutmelding staat.
User admin has been backed up. <16:35:00>
MKD /backup failed; [/backup: Permission denied]
ncftpput: Could not change to directory /backup: server said: backup: Permission denied

Wat heb ik exact gedaan...
Op mijn VPS waar DA opstaat (IP 85.234.197.11, hostname v01.s01.be.it2go.eu) de admin backup/restore gestart met de volgende waarden :
IP : 85.234.197.4 (s04.be.it2go.eu)
Username : da-backup-v01
- wachtwoord : tja...het wachtwoord van deze user hé
Remote path : /backup

Ik vermoed dat de fout ligt aan dat remote path. Hoe moet ik deze exact ingeven? Op mijn voip bak heb ik namelijk een gebruiker da-backup-v01 aangemaakt en deze ook een map gegeven in de /home. In die map heb ik dan een map backup aangemaakt. Moet ik dan bij remote path /backup gebruiken, of /home/da-backup-v01/backup of nog iets anders?

t.bloo
03/01/13, 22:35
effe vanaf de commandline handmatig uitproberen, dat is de beste methode om zoiets te testen

Vanuit DirectAdmin een remote backup is en blijft een lastig ding, geeft (bij mij) vaker allerlei fouten.

Keizer
04/01/13, 00:15
Het is de afgelopen versies ook een paar keer veranderd volgens mij.. eerst moest je een tijd zonder / doen, toen weer met, maar het ligt ook weer aan je (jailed) ftp account, of niet?

Een truc om te testen is om een user.admin.test.tar.gz in die /home/da-backup-v01/backup map te zetten en dan via de restore via FTP optie te testen of je hem te zien krijgt (je zult zien dat die instellingen ook boven komen te staan bij het opslaan van een backup cronjob). Als je de test ziet kan je de cronjob opslaan en werkt het, meestal ;)

oehTie
04/01/13, 14:29
omdat het al een aantal keer is veranderd gebruik ik de da-ftp niet meer.

Wij maken iedere dag van alle users een full backup naar /dabackup op de zelfde server, Gewoon een locale map dus. Vervolgens wordt na de backup een script gestart wat met nftp alle bestanden overzet naar een aparte fysieke machine. Die aparte backupmachine draait tegenwoordig windows 2012 met compressie en deduplicatie dus dubbele data wordt niet 2x opgeslagen. Scheelt bij mij 75% van de schijfruimte en dat loopt op naar mate er meer backups bijkomen.

Voordeel van deze setup is dat de laatste backup op de webserver blijft staan. Als een klant wat sloopt en ik diezelfde dag nog de restore regel hoef ik niet eerst de backup terug te halen vanaf een andere server. Nadeel is dat je webserver wat meer schijfruimte nodig heeft.

t.bloo
04/01/13, 15:33
Nadeel is dat je webserver wat meer schijfruimte nodig heeft.

Je kunt met ftpfs of sshfs makkelijk een share aanmaken op een andere server in de buurt, ziet er dan lokaal uit voor DirectAdmin en is nagenoeg net zo snel.

systemdeveloper
04/01/13, 15:39
Het is iets handiger om gewoon ssh keys te gebruiken en vanaf de backupserver de backups te pullen.
De backupserver timmer je dan verder gewoon dicht.

oehTie
05/01/13, 15:08
Je kunt met ftpfs of sshfs makkelijk een share aanmaken op een andere server in de buurt, ziet er dan lokaal uit voor DirectAdmin en is nagenoeg net zo snel.

klopt helemaal alleen directadmin kan nog altijd niet backups in mappen zetten en een x aantal dagen bewaren. Script wat ik gebruik upload naar /backupmap/datumvanvandaag

vDong
05/01/13, 15:30
Die aparte backupmachine draait tegenwoordig windows 2012 met compressie en deduplicatie dus dubbele data wordt niet 2x opgeslagen. Scheelt bij mij 75% van de schijfruimte en dat loopt op naar mate er meer backups bijkomen.

ZFS kan dit al jaren. Ook een beetje backuppakket doet dit standaard, ik zou niet willen aanraden daar een dure (per cpu!) windows licentie voor te nemen. Dit nog buiten dat er grote voordelen zijn bij het opslaan van backups op hetzelfde filesysteem (rechten, owners,etc) zodat bij (gedeeltelijke) restore deze dingen gelijk blijven.

ximple
07/01/13, 23:45
Wij maken de back-ups gewoon via de DirectAdmin API. We hosten niet meer dan 60 a 70 websites op een server waardoor het maken van volledige back-ups nooit langer dan een uurtje duurt. Alle webservers draaien virtueel en op een 100mbit poort. De nodes en externe back-up servers draaien allemaal op 1GBit zodat je makkelijk een stuk of 10 DirectAdmin installaties tegelijk kan laten back-uppen.

De DirectAdmin API verdeeld daarnaast de back-ups netjes in mapjes met de datum. Wij bewaren 3 dagen back-ups en drie van de afgelopen drie maanden. Kost wel meer opslag, maar het herstellen vanuit volledige back-ups gaat altijd het snelste en de hoeveelheid diskruimte die de meeste klanten verbruiken is maar 20% van de toegestane hoeveelheid. En schijfruimte (SATA) kost natuurlijk bijna niks.

IT-worX
08/01/13, 00:07
Vanaf vandaag gebeurd dit automatisch als volgt...
v01.s01.be.it2go.eu = vps op eigen server waar DA op draait, draait thuis, gigabit netwerk
s04.be.it2go.eu = server met 7 mappen (één voor elke dag van de week), draait thuis, nu nog 100mbit binnenkort gigabit
backup.be.it2go.eu = server in datacenter

Elke dag om 1u 's nachts maakt v01.s01.be.it2go.eu een backup van elke user en stuurt deze via het interne netwerk naar s04.be.it2go.eu. Backups beginnen om 1u, en zijn gedaan rond 4u (ongeveer 39GB). Zo heb ik 7 backups telkens (één week) hier thuis staan in geval van problemen.

De nacht van zaterdag op zondag, om 0u01 stuurt de interne backupserver (s04.be.it2go.eu) via rsync alle backupfiles door naar backup.be.it2go.eu aan een maximum snelheid van 5mbit (limited) zodat er nog wat speed overblijft voor de servers zelf. Zo heb ik de backup van zaterdagmorgen telkens ook op een externe server.

Volstaat dit denken jullie, of zie ik iets over het hoofd?

The-BosS
08/01/13, 01:36
Wij maken de back-ups gewoon via de DirectAdmin API. We hosten niet meer dan 60 a 70 websites op een server waardoor het maken van volledige back-ups nooit langer dan een uurtje duurt.

Dat is natuurlijk subjectief, 60 websites van 10GB elk zullen nog steeds langer duren dan 1000 websites van elk 100MB ;)


Vanaf vandaag gebeurd dit automatisch als volgt...
v01.s01.be.it2go.eu = vps op eigen server waar DA op draait, draait thuis, gigabit netwerk
s04.be.it2go.eu = server met 7 mappen (één voor elke dag van de week), draait thuis, nu nog 100mbit binnenkort gigabit
backup.be.it2go.eu = server in datacenter

Elke dag om 1u 's nachts maakt v01.s01.be.it2go.eu een backup van elke user en stuurt deze via het interne netwerk naar s04.be.it2go.eu. Backups beginnen om 1u, en zijn gedaan rond 4u (ongeveer 39GB). Zo heb ik 7 backups telkens (één week) hier thuis staan in geval van problemen.

De nacht van zaterdag op zondag, om 0u01 stuurt de interne backupserver (s04.be.it2go.eu) via rsync alle backupfiles door naar backup.be.it2go.eu aan een maximum snelheid van 5mbit (limited) zodat er nog wat speed overblijft voor de servers zelf. Zo heb ik de backup van zaterdagmorgen telkens ook op een externe server.

Volstaat dit denken jullie, of zie ik iets over het hoofd?

Ik zou die rsync gewoon elke dag rond een uur of 6 laten doen, zo ben je altijd maar 1 dag maximaal kwijt (in het geval er iets thuis gebeurt). En ik zou ook de periode wat verlengen met bvb 4x 1 per week en 2x of 3x 1 per maand bijhouden. Dit kan je door een simpel script op je backup server te gebruiken dat bvb elke maandaag de vorige zondag kopieert naar een map week/1 week/2 week/3 week/4 en dan het zelfde voor de maanden maar dan 1x per maand in plaats van per week.

IT-worX
08/01/13, 01:51
Klopt maar die rsync gebeurd tegen 5mbit...dus die is wel een tijdje bezig :-) Er moet in een account maar één mailtje bijkomen en alles gaat terug een re-sync krijgen. Daar ik niet heel mijn upload (10mbit) wil volgooien heb ik dit bewust op 5mbit gezet. Meerdere rsyncs bijhouden van meerdere weken is idd een goede oplossing waar ik eens over ga denken.

The-BosS
08/01/13, 02:05
Klopt maar die rsync gebeurd tegen 5mbit...dus die is wel een tijdje bezig :-) Er moet in een account maar één mailtje bijkomen en alles gaat terug een re-sync krijgen.

Ik volg je even niet, je rsynct toch gewoon de tarballs die directadmin gemaakt heeft van je lokale backup server naar je externe backup server (quote: "De nacht van zaterdag op zondag, om 0u01 stuurt de interne backupserver (s04.be.it2go.eu) via rsync alle backupfiles door naar backup.be.it2go.eu"). De tijd dat je het iedere dag doet (7x elke backup die paar uur eerder gemaakt is) is net zolang als 1 keer per week (1x alle backups van die week).

Als in 1x per dag 39GB rsync'en zal even lang duren per week bekeken dan 1x per week 273GB (7x 39GB) rsync'en. Naast het feit dat je ongeveer aan 600KB/sec upload en je dus +- 28 min nodig hebt voor 1GB of +- 18 uur voor je backup van 39GB. Of als je het 1 maal per week doet ben je 127,5 uur (+- 5 dagen) bezig.

Tim.Bracquez
08/01/13, 02:33
@The-BosS: Zoals ik het begrijp backupt hij elke dag lokaal. En gaat hij maar 1 backup/dag extern opslaan... Voor als het lokaal afbrand...

IT-worX
08/01/13, 02:42
Tim : klopt

Arieh
08/01/13, 12:15
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.

ximple
21/01/13, 22:50
@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.

resultaat2012
24/01/13, 22:01
Wij maken gebruik van Continuous Data Protection® - Enterprise Edition. Perfect pakket voor backups

Pantsy
24/01/13, 22:02
Dan doel je op Idera (r1soft) neem ik aan =)

ErikKosters
28/01/13, 08:53
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.

resultaat2012
28/01/13, 11:14
Dat heb je goed.. Prima software

IT-worX
28/01/13, 11:52
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 :)

systemdeveloper
28/01/13, 12:04
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.

IT-worX
28/01/13, 12:22
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.

ichosting
29/01/13, 11:30
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.

DiederikL
29/01/13, 12:27
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.

systemdeveloper
29/01/13, 15:20
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.

jeroenedig
06/03/13, 17:39
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.