admin backup op lagere snelheid

[copyfile]

Op dit moment maar ik met een cronjob een backup naar een andere server in het zelfde netwerk. Hiervoor wordt de volledige 100mbit op dat moment vol gebruikt. Aangezien de backup zijde betaald per mbit's is dit niet echt handig. Is er een mannier om dit anders te regelen zodat de admin backup niet meer op volledige snelheid gaat maar op b.v. 20mbit/s ?

[Yourwebhoster]

Op dit moment maar ik met een cronjob een backup naar een andere server in het zelfde netwerk. Hiervoor wordt de volledige 100mbit op dat moment vol gebruikt. Aangezien de backup zijde betaald per mbit's is dit niet echt handig. Is er een mannier om dit anders te regelen zodat de admin backup niet meer op volledige snelheid gaat maar op b.v. 20mbit/s ?

Hoe doe je de backup momenteel? Via DA zelf?

Hier gaat de backup via rsync oa en daarmee kan je zelf de snelheid instellen. Tevens worden alleen de bestanden overgezet die alleen aangepast zijn, scheelt weer belasting van de server

[copyfile]

De backup gaat via DA zelf. Is het op die mannier niet mogelijk de snelheid te verlagen ?

[t.bloo]

DirectAdmin gebruikt ncftpput om tar bestanden naar de andere server te sturen. Dat programma heeft helaas geen throttle/limit opties, anders had je die in een wrapper kunnen gooien. Je kunt wel de verbinding naar je backupserver afknijpen natuurlijk.

[copyfile]

Hoe kan ik dat doen t.bloo ? Want dat is dan ook prima indien dit alleen naar de backup server toe is !

[Bart L]

FTP server limitten ;-) De meeste kunnen dat wel.

[Mikey]

Of op de source server via iptables ?

[ichosting]

Of op hardware niveau: je switchpoort knijpen op 10 mbit

Maar ik zou het inderdaad ook via rdiff of rsync doen. Scheelt je veel heen en weer gepomp.

[systemdeveloper]

Een backup binnen hetzelfde netwerk en dan afrekenen op mbitverbruik? Dat is een hele aparte situatie (imho) als die backup niet in een ander dc staat.

Staat backup in een ander dc -> mysqldump van de db's maken en het hele zooi rsyncen met bandwith-limit optie. Klaar en lekker trafficverbruik afrekenen.
Staat backup in hetzelfde dc/rack -> dan maak je gewoon een backup netwerk (eth1 server -> eth1 backupserver of met een aparte switch) en dan lekker vol gas backups trekken en afrekenen op GB's backupuimte. Backupspeed limiten in dit geval wil je eigenlijk alleen maar doen indien het anders je productieserver (disks oa) teveel gaat belasten.

Softwarematig kan uiteraard ook. Voor centos -> man tc, voor freebsd -> man opfw

[Randy]

Om pieken hoef je je bij Mbit 95% geen zorgen te maken, mits dit onder de 36 uur/maand blijft. Wanneer je gaat limiteren ben je langer bezig om de data over te zetten en betaal je uiteindelijk wel voor de traffic. Kijk dus eerst hoelang het versturen van de back-ups duurt. Bij minder dan een uur per dag hoef je je nog geen zorgen te maken.

[Apoc]

Om pieken hoef je je bij Mbit 95% geen zorgen te maken, mits dit onder de 36 uur/maand blijft. Wanneer je gaat limiteren ben je langer bezig om de data over te zetten en betaal je uiteindelijk wel voor de traffic. Kijk dus eerst hoelang het versturen van de back-ups duurt. Bij minder dan een uur per dag hoef je je nog geen zorgen te maken.

Daar is de 95% methode niet voor bedoeld hae

Meest voor de hand liggende oplossing lijkt me om gewoon een tweede (gigabit) uplink aan te sluiten op beide servers met een intern IP, en daar de backups overheen te gooien. Dan heb je snellere backups/restores (gigabit), geen verbruik van je publieke uplink en geen bottleneck.

[Alain]

Ten eerste is het vrij gebruikelijk backups over bv een lokaal netwerk te gooien want niemand wil zijn WAN netwerk belasten met backups die vaak korte tijd flink wat bursten. En als je dan ook nog eens voor dat verkeer moet betalen dan heb je op dat punt ook al een onwenselijke situatie.

Ten tweede is de ingebouwde DirectAdmin backup extreem inefficiënt en is het te adviseren om een andere manier van backuppen te gebruiken; hierboven las ik al wat voorbeelden. Alles is ongeveer beter dan de ingebouwde DirectAdmin, zeker als je alleen de wijzigingen gaat overzetten (wat vaak een fractie is van wat een fullbackup kost). Maar als je backups wilt gebruiken om altijd op terug te kunnen vallen, ook als je bv pas enkele dagen later ontdekt dat je iets mist, dan is simpel rsyncen ook niet zomaar de oplossing. Je moet dan gaan werken met een pakket waarbij je én alleen de wijzigingen over zet én je retentie hebt van meerdere dagen/weken of zelfs maanden. Bacula kan dan een mooie oplossing zijn.

[wijtec]

je zou ook de netwerkkaart van de backup server kunnen forceren op 10mbit met ethtool of mii-tool, of via iptables ratelimiten