gepackt … die CPU des Systems besch\u00e4ftigt sich alle paar Sekunden ein wenig mit dem Arbeiten und schl\u00e4ft ansonsten. Da ist also noch Spielraum f\u00fcr das Backup. Nehmen wir \/var dazu. Gleiche Vorgehensweise, nur auf einer weiteren Screen-Konsole. Auch hier ist er nur sporadisch am Arbeiten, was also andeutet, dass noch Platz f\u00fcr mehr Backup-Operationen sind. \/etc und \/usr noch erg\u00e4nzt und siehe da: die CPU hat nun auch etwas zu tun. Nebenbei liefen die normalen Services normal weiter (Brauchte haupts\u00e4chlich ein Backup zum Vorbereiten der Installation auf dem neuen Server. das eigentliche Kopieren der Daten wird dann bei abgeschalteten Diensten geschehen).<\/p>\n
Und nun: was kam dabei raus: Mit 4 mal Backup komprimieren und normal laufenden Hintergrunddiensten (die wahrscheinlich etwas tr\u00e4ger wie normal reagiert haben d\u00fcrften), kam der Server auf eine Durchschnittslast von sportlichen 9.27 im 15 Minuten-Durchschnitt. Eindeutig zu viel, um insgesamt etwa 4,5 GB Daten zu komprimieren, was geschlagene zweieinhalb Stunden ben\u00f6tigt hat.<\/p>\n
Aber gut, war in gewisser Hinsicht auch etwas verzerrend, gerade aber, wenn man solche Werde liest, auch wieder nicht:<\/p>\n
# time tar -czf home.tar.gz \/home\r\ntar: Entferne f\u00fchrende \u201e\/\u201c von Elementnamen\r\n\r\nreal\u00a0\u00a0\u00a0 104m41.106s\r\nuser\u00a0\u00a0\u00a0 4m53.859s\r\nsys\u00a0\u00a0\u00a0\u00a0 0m22.261s<\/pre>\nDie anderen Kompressionsvorg\u00e4nge sahen nicht wesentlich anders aus von den Zahlenverh\u00e4ltnissen …<\/p>\n
Daf\u00fcr ging die Server-zu-Server-Kopie anschlie\u00dfend richtig flott von der Hand (mit atemberaubenden 800 KB\\s). Selbst von meiner DSL-Leitung bin ich besseres gewohnt!<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"