Hallo,
Ich habe mir mal die Backupvarianten angeschaut um die TPS Drops während der Sicherung (auch künftig) zu verringern.
Getstet habe ich mit einer Welt die 6.7Gb hat (2b2t, habe leider keinen größeren Worlddownload gefunden).
Auf dem Server liefen eine diverse Dinge um ein wenig Lag zu verursachen und die TPS zu drücken. TPS waren zwischen 17.5 – 18.5, hat ein wenig variiert. Ausgestattet war der Server recht spärlich: 2 CPU á 2095 MHz und 4Gb RAM.
CPU lief während den Tests auf Vollast. TPS wurden im 5 Sekundentakt erfasst.
Folgendes wurde getestet:
Bei den Sicherungen per tar habe ich mir das rüberkopieren per SCP gespart, hätte die Sache sicherlich nicht besser gemacht.
Über die Qualität der Shellscripte können wir später streiten. Der Zweck wurde erfüllt.
1. tar ohne ionice
tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
230.40s user 25.41s system 90% cpu 4:43.52 total
2. tar mit ionice -c3
Das ist die Methode die momentan wohl laut @Zweistein2 verwendet wird.
ionice -c3 macht gefühlt keinen großen Unterschied :/
ionice -c3 tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
230.98s user 27.76s system 89% cpu 4:48.95 total
3. tar in docker Container mit Bandbreitenlimit von 20Mb
Danach dachte ich, vielleicht kann man die Bandbreite mit einem Contrainer besser drosseln. Hat soweit auch funktioniert, I/O sind jedenfalls sehr gering, dafür dauert das Backup entsprechend länger. TPS droppen auch nicht mehr so extrem wie zuvor.
docker run -it --rm --name minecraft_backup -w /tmp/minecraft -v /tmp/minecraft:/tmp/minecraft --device-read-bps=/dev/system/root:20mb --device-write-bps=/dev/system/root:20mb alpine time tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
4. tar ohne Kompression
Nun nochmal das Ganze ohne Kompression, sollte die Last der CPU deutlich reduzieren.
Läuft ratz fatz. Dafür ist die Filesize natürlich größer. TPS drop ist auch hier vorhanden, jedoch deutlich geringer.
tar cvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/backup/world
0.80s user 16.72s system 45% cpu 38.669 total
Aber warum überhaupt erst Lokal speichern und dann per SCP übertragen? Warum nicht gleich per SSH auf den Zielserver übertragen und dort komprimieren?
5. tar über ssh (50Mbit Leitung)
Reduziert immerhin die Write I/O. TPS drop ähnlich wie bei der Docker Variante. Habe den Versuch dann aber abgebrochen nach ein paar Minuten.
tar cvf - /tmp/minecraft/world | ssh -p 56022 root@192.168.2.2 "gzip -6 > /tmp/foo.tar.gz"
6. tar über ssh (1Gbit+ Leitung)
Diesmal wurde das Backup auf einen anderen Server kopiert. Dieser hatte auch eine ordentliche Anbindung.
TPS drop ist ähnlich wie bei dem Test mit einer 50Mbit Bandbreite.
tar cvf - /tmp/minecraft/world | ssh kreck@x.x.x.x "gzip -9 > ~/foo.tar.gz"
Um ein paar Files zu ändern habe ich random den Zeitstempel von Files geändert
find /tmp/minecraft/world/region -name '*.mca' -type f -exec bash -c '(($RANDOM%5)) && touch {}' \;
7. rsync
rsync -av /tmp/minecraft/world/ -e 'ssh -p xxx' kreck@x.x.x.x:~/world/
31.39s user 11.34s system 12% cpu 5:34.91 total
leider habe ich hier keine I/O Stats.
8. rsync mit Bandbreitenlimit ~10Mb
Ähnlich wie ohne Limitierung. TPS Drop ebenfalls vorhanden, aber nicht mehr so stark. Dauer des Backups ist trotzdem deutlich reduziert.
rsync -av --bwlimit=10000 /tmp/minecraft/world/ -e 'ssh -p xxx' kreck@x.x.x.:~/world/ 32.53s user 9.99s system 14% cpu 4:51.02 total
9. borg
Darauf hat mich @minifisch in Discord gebracht. Repository liegt ebenfalls auf einem anderen Server.
I/O ist hoch, Impact der TPS auch. Aber – es geht verdammt schnell.
borg create --stats --compression none ssh://kreck@x.x.x.x:xxxx/home/kreck/borg::minecraft_$(date +%Y.%m.%d_%H.%M) /tmp/minecraft/world
51.61s user 6.01s system 63% cpu 1:31.28 total
Nun musste ich ungefähr gleiche Verhältnisse herstellen um rsync und borg vergleichen zu können. Also habe ich bei den ersten 500 Dateien den Zeitstempel geändert und dann die Sicherung gestartet.
COUNT=1; for i in $(ls /tmp/minecraft/world/region); do [ $COUNT -le 500 ] && touch /tmp/minecraft/world/region/$i; [ $COUNT -eq 500 ] && break; ((COUNT=$COUNT+1)); done
buuh Output von ls soll man nicht parsen ...
10. borg mit 500 geänderten Files (timestamp)
TPS drop auch vorhanden (wie zuvor), jedoch wenigster stark. Backup ist auch schnell durchgelaufen.
borg create --stats --compression none ssh://kreck@x.x.x.x:xxxx/home/kreck/borg::minecraft_$(date +%Y.%m.%d_%H.%M) /tmp/minecraft/world
10. rsync mit 500 geänderten Files (timestamp)
I/O Impact ist geringer, jeodoch dauert die Sicherung ein wenig länger. TSP drop ist <1 TPS weniger im Vergleich zu borg.
rsync -av -e 'ssh -p xxx' /tmp/minecraft/world/ kreck@x.x.x.x:/home/kreck/world/
Nun fiel mir noch ein das rsync den --no-whole-file Switch hat für Übertragungen übers Netz.
11. rsync mit 500 geänderten Files (timestamp) und --no-whole-file Switch
Wieder eine kleine Verbesserung.
rsync -av --no-whole-file -e 'ssh -p xxx' /tmp/minecraft/world/ kreck@x.x.x.x:/home/kreck/world/
Vergleich TPS borg/rsync --no-whole-file
Komplette Übersicht
Zusammenfassung
tar in jeglicher Form scheidet aus. Ich denke die Wahl sollte auf rsync + rsnapshot oder borg fallen. Vielleicht gibt es bei borg ebenfalls noch Optimierungen. Ich habe das Tool zum ersten mal Benutzt und bin mit den Einstellungen noch nicht vertraut.
Was man jedoch sagen kann: beide sind schneller, sichern inkrementell und vergingern die Last deutlich.
Man muss natürlich prüfen wie sich die Performance auf einem Server mit mehr Kernen, RAM und einer größeren Welt verhält, aber für einen groben Überblick sollte das erstmal reichen.
Falls noch jemand weitere Vorschläge hat nehme ich diese gerne an.
Danke an @Iglo für das bereitstellen eines Server der mir als Backuprepository gedient hat.
Danke @minifisch für den Vorschlag von borg, das werde ich mir mal genauer ansehen.
Gruß
__kreck
Ich habe mir mal die Backupvarianten angeschaut um die TPS Drops während der Sicherung (auch künftig) zu verringern.
Getstet habe ich mit einer Welt die 6.7Gb hat (2b2t, habe leider keinen größeren Worlddownload gefunden).
Auf dem Server liefen eine diverse Dinge um ein wenig Lag zu verursachen und die TPS zu drücken. TPS waren zwischen 17.5 – 18.5, hat ein wenig variiert. Ausgestattet war der Server recht spärlich: 2 CPU á 2095 MHz und 4Gb RAM.
CPU lief während den Tests auf Vollast. TPS wurden im 5 Sekundentakt erfasst.
Folgendes wurde getestet:
- tar ohne ionice
- tar mit ionice -c3
- tar in docker Container mit Bandbreitenlimit von 20Mb
- tar ohne Kompression
- tar über ssh (50Mbit Leitung)
- tar über ssh (1Gbit+ Leitung)
- rsync
- rsync mit Bandbreitenlimit ~10Mb
- borg
- borg mit 500 geänderten Files (timestamp)
- rsync mit 500 geänderten Files (timestamp)
- rsync mit 500 geänderten Files (timestamp) und --no-whole-file Switch
Bei den Sicherungen per tar habe ich mir das rüberkopieren per SCP gespart, hätte die Sache sicherlich nicht besser gemacht.
Über die Qualität der Shellscripte können wir später streiten. Der Zweck wurde erfüllt
.1. tar ohne ionice
tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
230.40s user 25.41s system 90% cpu 4:43.52 total
2. tar mit ionice -c3
Das ist die Methode die momentan wohl laut @Zweistein2 verwendet wird.
ionice -c3 macht gefühlt keinen großen Unterschied :/
ionice -c3 tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
230.98s user 27.76s system 89% cpu 4:48.95 total
3. tar in docker Container mit Bandbreitenlimit von 20Mb
Danach dachte ich, vielleicht kann man die Bandbreite mit einem Contrainer besser drosseln. Hat soweit auch funktioniert, I/O sind jedenfalls sehr gering, dafür dauert das Backup entsprechend länger. TPS droppen auch nicht mehr so extrem wie zuvor.
docker run -it --rm --name minecraft_backup -w /tmp/minecraft -v /tmp/minecraft:/tmp/minecraft --device-read-bps=/dev/system/root:20mb --device-write-bps=/dev/system/root:20mb alpine time tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
4. tar ohne Kompression
Nun nochmal das Ganze ohne Kompression, sollte die Last der CPU deutlich reduzieren.
Läuft ratz fatz. Dafür ist die Filesize natürlich größer. TPS drop ist auch hier vorhanden, jedoch deutlich geringer.
tar cvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/backup/world
0.80s user 16.72s system 45% cpu 38.669 total
Aber warum überhaupt erst Lokal speichern und dann per SCP übertragen? Warum nicht gleich per SSH auf den Zielserver übertragen und dort komprimieren?
5. tar über ssh (50Mbit Leitung)
Reduziert immerhin die Write I/O. TPS drop ähnlich wie bei der Docker Variante. Habe den Versuch dann aber abgebrochen nach ein paar Minuten.
tar cvf - /tmp/minecraft/world | ssh -p 56022 root@192.168.2.2 "gzip -6 > /tmp/foo.tar.gz"
6. tar über ssh (1Gbit+ Leitung)
Diesmal wurde das Backup auf einen anderen Server kopiert. Dieser hatte auch eine ordentliche Anbindung.
TPS drop ist ähnlich wie bei dem Test mit einer 50Mbit Bandbreite.
tar cvf - /tmp/minecraft/world | ssh kreck@x.x.x.x "gzip -9 > ~/foo.tar.gz"
Um ein paar Files zu ändern habe ich random den Zeitstempel von Files geändert
find /tmp/minecraft/world/region -name '*.mca' -type f -exec bash -c '(($RANDOM%5)) && touch {}' \;
7. rsync
rsync -av /tmp/minecraft/world/ -e 'ssh -p xxx' kreck@x.x.x.x:~/world/
31.39s user 11.34s system 12% cpu 5:34.91 total
leider habe ich hier keine I/O Stats.
8. rsync mit Bandbreitenlimit ~10Mb
Ähnlich wie ohne Limitierung. TPS Drop ebenfalls vorhanden, aber nicht mehr so stark. Dauer des Backups ist trotzdem deutlich reduziert.
rsync -av --bwlimit=10000 /tmp/minecraft/world/ -e 'ssh -p xxx' kreck@x.x.x.:~/world/ 32.53s user 9.99s system 14% cpu 4:51.02 total
9. borg
Darauf hat mich @minifisch in Discord gebracht. Repository liegt ebenfalls auf einem anderen Server.
I/O ist hoch, Impact der TPS auch. Aber – es geht verdammt schnell.
borg create --stats --compression none ssh://kreck@x.x.x.x:xxxx/home/kreck/borg::minecraft_$(date +%Y.%m.%d_%H.%M) /tmp/minecraft/world
51.61s user 6.01s system 63% cpu 1:31.28 total
Nun musste ich ungefähr gleiche Verhältnisse herstellen um rsync und borg vergleichen zu können. Also habe ich bei den ersten 500 Dateien den Zeitstempel geändert und dann die Sicherung gestartet.
COUNT=1; for i in $(ls /tmp/minecraft/world/region); do [ $COUNT -le 500 ] && touch /tmp/minecraft/world/region/$i; [ $COUNT -eq 500 ] && break; ((COUNT=$COUNT+1)); done
buuh Output von ls soll man nicht parsen ...
10. borg mit 500 geänderten Files (timestamp)
TPS drop auch vorhanden (wie zuvor), jedoch wenigster stark. Backup ist auch schnell durchgelaufen.
borg create --stats --compression none ssh://kreck@x.x.x.x:xxxx/home/kreck/borg::minecraft_$(date +%Y.%m.%d_%H.%M) /tmp/minecraft/world
10. rsync mit 500 geänderten Files (timestamp)
I/O Impact ist geringer, jeodoch dauert die Sicherung ein wenig länger. TSP drop ist <1 TPS weniger im Vergleich zu borg.
rsync -av -e 'ssh -p xxx' /tmp/minecraft/world/ kreck@x.x.x.x:/home/kreck/world/
Nun fiel mir noch ein das rsync den --no-whole-file Switch hat für Übertragungen übers Netz.
11. rsync mit 500 geänderten Files (timestamp) und --no-whole-file Switch
Wieder eine kleine Verbesserung.
rsync -av --no-whole-file -e 'ssh -p xxx' /tmp/minecraft/world/ kreck@x.x.x.x:/home/kreck/world/
Vergleich TPS borg/rsync --no-whole-file
Komplette Übersicht
Zusammenfassung
tar in jeglicher Form scheidet aus. Ich denke die Wahl sollte auf rsync + rsnapshot oder borg fallen. Vielleicht gibt es bei borg ebenfalls noch Optimierungen. Ich habe das Tool zum ersten mal Benutzt und bin mit den Einstellungen noch nicht vertraut.
Was man jedoch sagen kann: beide sind schneller, sichern inkrementell und vergingern die Last deutlich.
Man muss natürlich prüfen wie sich die Performance auf einem Server mit mehr Kernen, RAM und einer größeren Welt verhält, aber für einen groben Überblick sollte das erstmal reichen.
Falls noch jemand weitere Vorschläge hat nehme ich diese gerne an.
Danke an @Iglo für das bereitstellen eines Server der mir als Backuprepository gedient hat.
Danke @minifisch für den Vorschlag von borg, das werde ich mir mal genauer ansehen.
Gruß
__kreck
Zuletzt bearbeitet:
