Bearbeiten von „Geschichte/Server/top4“
Aus UUGRN
Warnung: Du bist nicht angemeldet. Deine IP-Adresse wird bei Bearbeitungen öffentlich sichtbar. Melde dich an oder erstelle ein Benutzerkonto, damit Bearbeitungen deinem Benutzernamen zugeordnet werden.
Die Bearbeitung kann rückgängig gemacht werden. Bitte prüfe den Vergleich unten, um sicherzustellen, dass du dies tun möchtest, und speichere dann unten deine Änderungen, um die Bearbeitung rückgängig zu machen.
| Aktuelle Version | Dein Text | ||
| Zeile 3: | Zeile 3: | ||
{{Navigationsleiste Systeme}} | {{Navigationsleiste Systeme}} | ||
__TOC__ | __TOC__ | ||
| + | |||
| + | == Server Forschung nach Rabe == | ||
| + | |||
| + | '''2018-10-22 (~sdk) - Noch mehr Server''' | ||
| + | |||
| + | Ich habe beim rumspielen entdeckt, dass das stadtwiki (ist das == rhein-neckar-wiki?) auf stwserv3.stwserv.de laufen. Dort kommt man von top aus drauf. | ||
| + | |||
| + | Dann gibts noch srv01.sigsys.de, worauf wir aber zur Zeit (afaik) keinen Zugriff haben. | ||
| + | |||
| + | '''2018-10-22 (~sdk) - Admin ML''' | ||
| + | |||
| + | Es gibt nun eine admin Mailing Liste: http://mailman.uugrn.org/mailman/listinfo/admin | ||
| + | |||
| + | Hmm, ich stelle grade fest, das dort auch alle cron jobs hin reporten. Will man das? | ||
| + | |||
| + | ---- | ||
| + | |||
| + | '''2018-10-22 (~sdk) - Offsite Backup? Wanted? Traffic?''' | ||
| + | |||
| + | Weiß jemand ob es für Top ein Offsite Backup gibt? Ich bin mir ziemlich sicher, dass top seine Daten nirgends hin pusht. Ob eine andere Maschine die Backups pullt kann ich nicht nachvollziehen. | ||
| + | |||
| + | ---- | ||
| + | |||
| + | '''2018-10-21 (~sdk) - Platte voll wegen Backup... was tun?''' | ||
| + | |||
| + | Wir haben aktuell das Problem, dass auf top immer mal wieder die Platte voll läuft und viele Dienste und Jails dann nicht mehr ordnungsgemäß arbeiten. | ||
| + | |||
| + | Täglich läuft ein cronjob, der das script <code>/root/bin/zfs_backup3.sh</code> ausführt. Dieses Script erzeugt Snapshots und sichert diese zusätzlich in <code>/data/backup/uugrn.org/</code>. | ||
| + | |||
| + | Ich verstehe nicht, warum Snapshots zusätzlich nach <code>/data/backup/uugrn.org</code> gesichert werden, da dieses Verzeichnis auf dem selben Festplattenverbund liegt. | ||
| + | |||
| + | Mein Vorschlag wäre dieses selbstgebastelte Konzept gegen <code>zfs-auto-snapshot</code> auszutauschen. | ||
| + | |||
| + | Vorschlag für einen crontab Eintrag für <code>zfs-auto-snapshot</code>: | ||
| + | <pre> | ||
| + | 15,30,45 * * * * root /usr/local/sbin/zfs-auto-snapshot frequent 3 | ||
| + | 0 * * * * root /usr/local/sbin/zfs-auto-snapshot hourly 24 | ||
| + | 7 0 * * * root /usr/local/sbin/zfs-auto-snapshot daily 7 | ||
| + | 14 0 * * 7 root /usr/local/sbin/zfs-auto-snapshot weekly 4 | ||
| + | 28 0 1 * * root /usr/local/sbin/zfs-auto-snapshot monthly 12 | ||
| + | </pre> | ||
| + | |||
| + | `zfs-auto-snapshot` managed darufhin die snapshots auf dataset ebene und kann pro dataset an und abgeschaltet werden (über ein zfs attribut). Die Zahl rechts neben hourly/daily/weekly etc. gibt an wie viele des entsprechdenen Snapshot-Typs erhalten bleiben sollen. | ||
| + | |||
| + | Auf eine zusätzliche, zweite Sicherung der Snapshots würde ich verzichten. | ||
| + | |||
| + | Mit diesem Konzept steigt die Speicherlast nicht sprungartig an, sondern lediglich Speicher gelöschter Dateien wird erst 12 Monate später frei gegeben. Ggf. können wir das auf 6 Monate reduzieren. | ||
| + | |||
| + | Wissen die Mitglieder eigentlich, dass sie Zugriff auf die Snapshots über das versteckte Verzeichnis <code>/.zfs</code> haben? | ||
| + | |||
| + | ---- | ||
| + | |||
| + | == -------------- == | ||
== Hardware == | == Hardware == | ||
