DirectAdmin gebruikers : hoe maak jij jouw backup?

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?

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.

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 ;)

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.

Citaat:

---

Oorspronkelijk geplaatst door oehTie

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.

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.

Citaat:

---

Oorspronkelijk geplaatst door t.bloo

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

Citaat:

---

Oorspronkelijk geplaatst door oehTie

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.

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.

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?

Citaat:

---

Oorspronkelijk geplaatst door ximple

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 ;)

Citaat:

---

Oorspronkelijk geplaatst door IT-worX

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.

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.

Citaat:

---

Oorspronkelijk geplaatst door IT-worX

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.

@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...

Tim : klopt