So, mal noch eine kurze Rückmeldung. Ich habe am Wochenende den Server noch einmal komplett herunter, um die SATA-Anschlüsse zu prüfen. Mit der Folge, dass danach keine einzige VM mehr starten wollte (es konnte keine Verbindung zur VM aufgebaut werden). Ich habe Stunden damit verbracht, das zu analysieren. Ich war schon kurz davor, ESXi neu zu installieren. Letzter Versuch nach zweimaligem Ausschalten + Server stromlos machen - und die VMs starteten wieder einwandfrei. Und was soll ich sagen: seither ist der Zugriff auf die Pool-Übersicht oder die Filesysteme wieder in ordentlicher Zeit da. Keine Ahnung, was der Kiste quer im Magen lag. Sowas mag ich ja gar nicht, Probleme, die kommen und gehen, ohne dass man erkennen könnte, warum… Napp-It war jedenfalls nicht schuld, sondern offenbar das Blech... 😉
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 543
Du hastest ja im März schon so komische Effekte nach dem ausschalten denk ich, was ist denn da für ne Hardware drunter?
Also Mainboard, Controller etc?
Also Mainboard, Controller etc?
Könntest Du darauf bitte noch einmal näher eingehen? „Sonstige“ Snaps sind dann solche Snaps, die nicht vom Replikationsjob erstellt werden? Davon habe ich durchaus einige. Wie spielt das zusammen mit Snaps, die durch einen Autosnap Job erstellt wurden? Szenario wäre ja: Autosnap erstellt häufig und viele Snaps, um versehentlich durchgeführte Veränderungen rückgängig machen zu können. Replikationsjobs für Backup werden hingegen in geringerer Frequenz durchgeführt, als die Autosnap Jobs. Führt das bei Replikationsjobs dann zu Problemen? Und wie ist das dann bei hold/keep in den Replikationsjobs? Wenn nur die letzten x pro Tag/Woche/Monat/Jahr gehalten werden - werden die ältesten dann mit der nächsten Replikation gelöscht? Und was würde mit den Snaps aus dem o.g. Autosnap Job passieren, die ggf. länger leben sollen? Verschwinden die mit dem entfernen eines Replikations-Snaps, der seine Halbwertszeit überschritten hat? Bzw. bleibt die Integrität der Snapshot-Kette dann noch erhalten, wenn ein solcher Snap gelöscht wurde? Also
Manueller-Snap1
Replikations-Snap (veraltetet) -> wird gelöscht
Manueller-Snap2
Sorry für die vielen Fragen…
Beitrag automatisch zusammengeführt:
Will ich nicht ausschließen. Hardware siehe System in meinem Profil - sollte gepflegt sein. 😉
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 543
OK, also bei der Hardware musst du schon mal damit rechnen, das es so komische Effekte gibt.
Elektronik altert einfach.
Elektronik altert einfach.
Das einzige Fehlverhalten, was ich ggf. auf Hardware schieben würde, wäre das im März berichtete nicht herunterfahren wollen der Napp-It VM. Ich denke inzwischen, dass der damalige Datenverlust des Paperless Docker Containers eher ein Docker Problem war (was ich zugegebenermaßen aber noch nicht verstanden habe…).
Ansonsten zur Hardware selbst: ja, nicht mehr die Jüngste, Spinnweben sind aber noch keine dran und weggerostet ist auch noch nix. 😅 Aber vielleicht sollte ich nach 7 Jahren tatsächlich mal über einen Hardware Refresh nachdenken… Ich werde mal ein wenig stöbern…
Ansonsten zur Hardware selbst: ja, nicht mehr die Jüngste, Spinnweben sind aber noch keine dran und weggerostet ist auch noch nix. 😅 Aber vielleicht sollte ich nach 7 Jahren tatsächlich mal über einen Hardware Refresh nachdenken… Ich werde mal ein wenig stöbern…
Recursive Replikation überträgt alle datasets (auch tieferliegende Dateisysteme, Zvols, Snaps). Das kann manchmal Probleme bereiten wenn man nach der Erstreplikation erwas ändert. Replikations Snaps werden nach der Übertragung umbenannt (mit Hinweis auf die Regel um den Snap zu behalten)
Einfach ausprobieren.
ZFS Anyraid
Status: Projektidee
Idee: ZFS vdev aus Platten unterschiedlicher Kapazität
Zunächst für Mirrors, dann Raid-Z.
Umsetzung: Klarasystems (waren verantwortlich für OpenZFS Fast Dedup)
Ziel: bessere Nutzung der Kapaazität, kleinste Platte bestimmt nicht mehr die vdev-Größe
also was Richtung Echtzeit Unraid oder Synology SHR
hexos.com
Status: Projektidee
Idee: ZFS vdev aus Platten unterschiedlicher Kapazität
Zunächst für Mirrors, dann Raid-Z.
Umsetzung: Klarasystems (waren verantwortlich für OpenZFS Fast Dedup)
Ziel: bessere Nutzung der Kapaazität, kleinste Platte bestimmt nicht mehr die vdev-Größe
also was Richtung Echtzeit Unraid oder Synology SHR
Introducing ZFS AnyRaid, Sponsored by Eshtek — HexOS
At the beginning of this year, we made the decision to invest a substantial chunk of capital to support an open source project for which we have great personal interest. ZFS AnyRaid will give users the ability to mix different sized drives in a pool, a highly-requested feature since our la
hexos.com
Hoffentlich wird das *irgendwann* gefixt: https://www.illumos.org/issues/4896
Das erklärt meine miese Pool Performance unter OmniOS ziemlich gut, während unter TrueNAS Scale 25.04 alles flutscht.
Das erklärt meine miese Pool Performance unter OmniOS ziemlich gut, während unter TrueNAS Scale 25.04 alles flutscht.
Luckysh0t
Enthusiast
Das habe ich vor ein paar Jahren auch festgestellt, mit einem Freund, als wir OmniOS als Alternative zu Solaris getestet hatten als VM Filer....aber das war wirklich ein graus...
Mittlerweile nutze ich OmniOS als FIler, aber wie schon mein Solaris direkt auf Blech. Allerdings nur mit einem HDD Mirror und Gbit Lan..mit Verschlüsselung. Solaris ist ca. +-20 MB/s schneller.
Für mich ist OmniOS damit solange raus. Hab aber keine Lust wieder zurück zu Solaris zu gehen. Ich werde solange Truenas Scale nochmal eine Chance geben, auch wenn ich die UI für zu fancy und aufgeblasen finde.
@gea kann man napp-it auch für ein Plain FreeBSD Stable benutzen ?
@gea kann man napp-it auch für ein Plain FreeBSD Stable benutzen ?
Zuletzt bearbeitet:
ja, napp-it cs.
Ich habe allerdings noch kein howto dabei, um Apache zu installieren und zu starten. Man müsste sich an der Proxmox oder OSX Anleitung orientieren oder das Web Frontend auf Windows oder Linux/Proxmox laufen lassen und nur den backend server starten um Free-BSD remote zu managen.
