Mit den üblichen Backup-Programmen wie Time-Machine, Back-in-Time, Veeam etc. hat man üblicherweise eine Backup-Historie, ohne dass es eines Snapshots bedarf.
Beiträge von Anthracite
-
-
Wenn sich der Keller nicht 5 Etagen tiefer befinden würde, wäre das auch meine Option gewesen
Und lass mich raten, es ist nicht daran gescheitert, weil du zu faul zum runtertragen wärest
In vielen Häusern gibt es Kabelschächte, in die dann auch noch ein LWL-Kabel passt. Manchmal kann auch ein Kabel von Kabelfernsehen dafür zweckentwendet werden. Aber in Mietwohnungen macht man dann den Aufwand doch nicht.
-
Dann kannste die Dateien ja von Usprungsort wiederherstellen, wenn nicht, dann jst das NAS KEIN Backup.
Im Prinzip richtig, aber dabei geht die Backuphistorie verloren, und die hätte man eigentlich schon ganz gerne. Gut, jetzt könntest du sagen, dann muss man für die Historie ein Backup vom Backup machen, aber es ist durchaus ein Kompromiss, darauf zu verzichten, und im Ernstfall verliert man halt die Historie.
-
Wenn das RAID 1 mit den beiden SSDs der limitierende Faktor sein sollte,
Zwei SSDs im Raid 1 können lesend 10GbE ausnutzen, schreibend hingegen nicht. Es kann aber andere Bremsen geben, z. B. Prozessorleistung, Dateigröße oder manchmal auch die Messmethode.
Selbst wenn der Qnap QNA-T310G1T Adapter nur "summen" sollte wäre das für mich am lüfterlosen MacBook Air irgendwie uncool.
Das sehe ich übrigens auch so. Es war eine sehr gute Aktion hier, das NAS in den Keller zu verbannen.
Ich werde berichten wo die Reise hingeht
Ja, mach mal.
-
Das muss nicht am NAS liegen, denn in anderen Anwendungen funktioniert nfs genauso wie bisher auch.
Dein Shield 2017 basiert auf Kodi. Ich würde daher mal suchen nach Problemen, die es unter Kodi mit nfs gibt.
Es könnte auch an Einstellungen für nfs auf dem NAS liegen. Zwischen nfs 3 und nfs 4 gibt es große Unterschiede. Versuch es mal, am NAS nur Version 3 und mal nur Version 4 einzuschalten, ob dir das weiterhilft.
Leider kann ich dir keine konkreteren Tipps geben, da ich das Shield 2017 nicht habe.
-
iscsi benötigt ein eigenes Volume. Wenn in dem Speicherpool kein Platz mehr vorhanden ist, muss ein bestehendes Volume verkleinert werden. Beim Verkleinern besteht potentiell das Risiko eines Datenverlustes (z. B. durch Stromausfall im falschen Moment). Daher ein Backup der Daten vor dem Verkleinern machen.
iscsi synchronisiert nicht zwischen den Zugriffen durch verschiedene Rechner. Wenn von zwei verschiedenen Rechnern gleichzeitig auf das gleiche iscsi zugegriffen wird, kann es Datenverluste geben.
Wenn iscsi einmal eingerichtet ist und dann nur du darauf zugreifst, gibt es kein besonderes Risiko von Datenverlusten (außer denen, die immer bestehen wie Schadprogrammen oder Fehlbedienungen, aber das betrifft Freigaben genauso).
-
-ppassword
Da steht jetzt sicher nicht 'password', sondern dein richtiges Passwort?
Die Fehlermeldung tritt aber üblicherweise auf, wenn der MySQL- oder MariaDB-Server (=Daemon) nicht gestartet ist. Siehe z. B. hier.
Die Meldung bedeutet, dass der Befehl mit Super-User-ID ausgeführt werden muss - also mit dem root-Account (admin).
Ein sudo vor dem Befehl tut's auch und ist das Gleiche. (Dr Mike weiß das sicherlich; das ist eine Info für BillBeaver.)
-
Und es geht um RJ45
Tja, Pech gehabt ...
Nimm einfach einen der von dir erwähnten Adapter von OWC oder Sonnet. Lt. Hersteller sind die tatsächlich lüfterlos. Die Geräuschlosigkeit ist den Aufpreis wert, und eine Umstellung auf sfp+ und Glasfaser/DAC wäre deutlich teurer. Da ich die beiden Adapter nicht kenne, kann ich keine weiteren Aussagen dazu machen, aber entweder er funktioniert oder er funktioniert nicht, das hast du schnell raus.
Glasfaser also SFP nehmen da Lüfterlos!
Du meinst sicherlich sfp+.
sfp ohne Plus gibt es auch. Der Unterschied ist, dass sfp nur Gigabit kann. Heute ist sfp ohne Plus deswegen nicht mehr aktuell, aber gerade, wenn man gebraucht kauft, muss man aufpassen, nicht das ältere sfp zu erwischen. sfp und sfp+ haben denselben Schacht und sind begrenzt kompatibel zueinander, manche Kombinationen funktionieren, andere nicht, aber sobald irgendwo sfp ohne Plus im Einsatz ist, ist die Geschwindigkeit auf Gigabit begrenzt.
-
Der Ersteller hatte eigentlich anderes im Sinn
Was denn?
wer hat schon Glasfaser am Arbeitstisch anliegen
Wenn ohnehin ein Switch am Schreibtisch stehen soll, nimmt man halt einen mit sfp+ Port. Ein DAC-Kabel oder LWL-Patchkabel ist dann kein großes Ding. Problem gelöst.
-
Meine Empfehlung:
- ein sfp+ Port
- bei Kauf (war 2020) mit Abstand der billigste Thunderbolt3-10GbE-Adapter
- relativ klein
- an der Leistung gibt es nichts auszusetzen
- lüfterlos und damit vollkommen lautlos
Hinweis: Der Qnap QNA-T310G1T mit rj45-Port für 10GbE über herkömmliches Kupfer ist nicht lüfterlos und somit nicht lautlos. Wie störend das Geräusch ist, weiß ich nicht, da ich ihn nicht kenne.
Und da ich annehme, dass Qnap den Lüfter nicht in die rj45-Variante einbaut, um die Kunden zu ärgern, sondern es einen Sinn haben wird, denke ich, dass es keine gute Idee sein wird, den sfp+ Adapter dauerhaft mit einem rj45-Transceiver, der relativ viel Strom verbraucht, zu nutzen. Transceiver für LWL und DAC-Kabel sind sparsamer. Mit LWL-Transceiver wird der Adapter angenehm handwarm, aber nicht so heiß, dass man sich um Adapter oder Umgebung Sorgen machen müsste. Der Switch auf der Gegenseite braucht dann natürlich auch einen sfp+ Port.
Unterhalb von 200€ gibt es da gefühlt nichts - und die Lösung von Qnap soll zudem auch relativ viel "Krach" machen was uns stören würde.
Das mit Qnap und Krach stimmt für den genannten sfp+ Adapter definitiv nicht. Der ist absolut lautlos.
Was den Preis angeht - nun, ich habe meinen Adapter vor drei Jahren gekauft und seitdem den Markt nicht mehr beobachtet. Ich habe aber das Gefühl, dass sich da nicht viel getan hat.
-
Die Platte 2 steht auf deiner Bildschirmkopie im Status "Suche nach fe...". Falls immer noch so, geh mal mit der Maus rüber, was das komplett heißt.
Falls die Platte mittlerweile im Status "bereit" angekommen sein sollte: Macht jetzt das Raid ein Rebuilt?
Und bitte Geduld. Ein Rebuilt kann durchaus 24 Stunden dauern.
Möglicherweise kann man das Raid auf Shell-Ebene mit Linux-Befehlen (z. B. mdadm) auch dann wieder aktivieren, wenn es über die Web-Oberfläche oder automatisch nicht mehr geht. Da man hier aber auch viel zerschießen und endgültig zerstören kann, würde ich das nur angehen zusammen mit dem Qnap-Support.
-
ist das normal, dass sich so ein Teil im Dauerbetrieb irgendwann auflöst?
In der Form? Nein.
Im Forum habe ich noch nicht davon gelesen, das ein NAS Stecker zum Schmelzen gebracht hätte. Klar, Defekte aller Art gibt es, aber meistens ist das Gerät einfach tot.
droht entweder die Sicherung (kommt die dann irgendwann?) oder ein Feuer
Meistens knallt irgendwann die Sicherung durch. Die Erhitzung kann zur Folge haben, dass der Strom besser fließt, so dass schnell die Stromstärke erreicht wird, bei der eine Sicherung reagiert.
Oder nach einigen Minuten ist weggekokelt, was kokelt kann, und der Strom fließt deswegen nicht weiter.
Ein sehr geringes Restrisiko bleibt aber, dass es längere Zeit kokelt, ohne dass die maximale Stromstärke überschritten wird. Das liest man manchmal nach Bränden in der Zeitung, Ursache war ein defektes Küchengerät o. Ä.. Entfernte Bekannte hatten mal einen Brand in der Wohnung, weil ein Deckenstrahler defekt war - die Bude ist nicht mit abgefackelt, aber der finanzielle Schaden durch den Rauch in der ganzen Wohnung war erheblich. Helfen kann, das NAS (oder sonstiges Gerät) so aufzustellen, dass keine brennbaren Materialien in der Nähe oder darüber sind.
-
Tja, was soll ich sagen...damit bekommt der Docker eine Ressource auf der Festplatte...
Das ist dann die richtige Lösung. Dann läuft die Ramdisk auch nicht voll, selbst wenn ein Programm im Docker mehrere Gigabyte Plattenspeicher nutzt.
Die Vergrößerung der Ramdisk in autorun.sh ist dann vermutlich nicht mehr nötig. Du kannst es ja mal beobachten, die Vergrößerung erst einmal drin lassen und gegebenenfalls später rausnehmen. Wobei, so viel RAM, wie du hast, ist das eigentlich auch egal.
-
könnte ich die Autorun.sh so schreiben?
Nein.
Du müsstest das in etwa so machen:
Codecp -Rp /unifi/* /share/Container/unifi/ rm -rf /unifi 2>/dev/null ln -s /share/Container/unifi /unifiBitte unbedingt aufpassen mit rm -rf. Wenn dir zwischen / und unifi versehentlich ein Leerzeichen gerät, crashst du das ganze System. (Hast du eigentlich ein Backup?)
Die Befehle kannst du einmal ausprobieren , bevor du sie in autorun.sh einbaust. Ich habe sie bei mir nicht getestet. Zum Ausprobieren wird eventuell ein sudo davor benötigt.
Der cp-Befehl ist überflüssig, wenn Unifi zu dem Zeitpunkt noch nicht läuft oder noch nichts in das Verzeichnis geschrieben hat.
Und dann noch was: Entweder Ramdisk vergrößern oder Link anlegen, aber nicht beides.
Die beste Möglichkeit ist aber mMn., stattdessen die Konfiguration von unifi zu ändern (mein erster Vorschlag im vorangegangenen Beitrag).
-
auch bei der 7490... die 7490 hat auch die 7.36 als Patch erhalten.
Für die 7490 gibt es übrigens auch 7.57 mit der Wireguard-Implementierung. Nur so, falls es dir das Leben leichter macht.
-
Ups....
da würde ich sagen, nimmt fast unifi 49 MB von den 173 MB ein.
(denke ich muss nicht beide Verzeichnisse addieren...Ja, da hast du wohl den Schuldigen gefunden. Von den zur Verfügung stehenden 173MB sind 49MB prozentual gesehen doch ein dicker Batzen. Wenn Linux auf einer Festplatte installiert ist, sind 49MB im Root-Dateisystem kein Problem, aber bei Qnap in der Ramdisk sieht das anders aus.
Nein, du brauchst die Werte nicht zu addieren. Im Verzeichnis /unifi liegen 49MB, und von diesen 49MB liegen 49MB - also von Rundungsungenauigkeiten abgesehen fast alles - im Unterverzeichnis /unifi/controller.
Lösungsmöglichkeiten sind:
- In Unifi Konfiguration ändern, so dass Daten nicht mehr in /unifi, sondern in /share/freigabe/unifi ablegt, also auf einer Festplatte mit genug Platz (ob das geht, weiß ich nicht, ich kenne unifi nicht)
- Unifi löschen (nur dann sinnvoll, wenn unifi nur eine Spielerei ist und nicht wirklich benötigt wird)
- /unifi ersetzen durch einen symbolischen Link (mit ln -s erstellt) auf /share/freigabe/unifi. Dies muss nach jedem Rebbot geschenen, da dabei die Ramdisk neu aufgebaut wird, und zwar bevor Unifi gestartet wird, also entweder im Startscript von Unifi oder in autorun.sh
- Die Größe der Ramdisk in autorun.sh ändern wie oben beschrieben
Es genügt, eine der genannten Lösungen durchzuführen. Die anderen Lösungen sind dann nicht mehr notwendig.
=> hast du für die ganzen Befehle eine schöne Übersicht, oder ist das einfach Linux Wissen
Das sind Erfahrungen. Irgendwann stolpert man selbst über solche Probleme.
Zu einzelnen Befehlen gibt es mit befehl -h oder befehl --help oder man befehl (letzteres auf Linux und Mac, aber nicht auf Qnap) Informationen.
Welche Firmware ist aktuell installiert?
Ist egal. Das Problem hat nichts mit der Firmware zu tun, sondern dem Drittanbieterprodukt Unify.
-
Die Container Station kann ich natürlich auch deaktivieren, falls das hilft.
Das hilft schon insofern, als dass nur dort Programme laufen, die nicht von Qnap selbst ausgeliefert wurden. Wenn die Ramdisk schon voll ist, ist danach aber noch ein Reboot fällig, weil das Deaktivieren nicht ausreichen wird, wieder etwas aus der Ramdisk zu löschen.
Des weiteren gibt es noch den Tipp aus dem anderen Thread, die Ramdisk durch
Codemount -o remount,size=768m /zu vergrößern, entweder ständig in autorun.sh oder einmalig für einen Test, wobei dann ein sudo davor muss. Vergrößern ist nur erfolgversprechend, wenn die Ramdisk noch nicht voll ist.
Wenn du die Ramdisk vergrößert hast, kannst du mal die Container-Station wieder aktivieren, um zu sehen, ob nur ein bisschen Speicher in der Ramdisk fehlt oder ob die gleich wieder vollläuft (exorbitanter Bedarf eines Programmes oder ein Programm in Endlosschleife).
Auch kannst du versuchen, den Verursacher zu finden. Mit
Codesudo du -h -x --max-depth=2 /erhältst du einen schnellen Überblick, wo Speicher belegt ist. Die 2 kann durch eine andere Suchtiefe ersetzt werden, statt / kannst du in nachfolgenden Aufrufen auch ein anderes Verzeichnis angeben, welches du als zu voll verdächtigst.
-
Wie strikt sind die QNAP NAS Systeme, insbesondere das TS-264 dahingehend?
Qnap blockiert andere Karten nicht aktiv, aber der Treiber für die Karte muss im Linux-Kernel des qts enthalten sein.
Baugleiche Karten zu offiziell unterstützten funktionieren in jedem Falle, bei Karten mit demselben Chipsatz kann man zumindest hoffen, bei Karten mit anderem Chipsatz sieht es schlecht aus.
Jetzt weiß ich nicht, warum bei deinem NAS viel weniger Karten offiziell unterstützt werden als bei meinem. Wenn es daran liegen sollte, dass im DOM (dem Speicher für die Firmware) zu wenig Platz ist, und Qnap zum Platz sparen für das NAS jede Menge Treiber weggelassen hat, dann sieht es schlecht aus mit Karten, die in anderen NAS unterstützt werden. Es kann aber auch sein, dass es ein Platzproblem im Gehäuse ist, dann würden die Karten, die für andere NAS freigegeben sind, auch in deinem NAS funktionieren, vorausgesetzt, man schafft ihnen mit einer Bastelarbeit Platz.
Um Firmware-Updates würde ich mir nicht so viel Sorgen machen. Die Treiber müssen für die offiziell unterstützten Karten ja weiterhin vorhanden bleiben. Im schlimmsten Falle geht man auf die letzte funktionierende Version zurück.
daher habe mich jetzt doch für die QNAP 10G1T Karte entschieden
Oha, die ist wirklich relativ teuer.
Ich habe eine HP-Karte mit zwei sfp+ Ports, die baugleich zu einer offiziell unterstützten Emulex ist, und die funktioniert einwandfrei. Die Karte hat mich gebraucht bei Ebay gerade mal 35 Euro gekostet. Gebrauchte 10GbE-Ware gibt es teilweise recht günstig, weil Rechenzentren auf höhere Geschwindigkeit umstellen, aber nicht alles ist im Heimbereich brauchbar (Karten, Transceiver und Kabel schon, Switche eher nicht) und rj45 mit Kupfer findet man da normalerweise nicht.
-
Wenn Kupfer, dann scheint der 2104-2T eine vernünftige Wahl zu sein.
Und dann würde ich mit der 10GBit/s-Karte im NAS noch warten, bis die Geschwindigkeit abgerufen werden kann.
Ein Hinweis: Wenn du einen Wifi7-AP mit 10GBit/s anschließen willst, das NAS und einen PC per Kabel mit der gleichen Geschwindigkeit, dann fehlt dir ein 10GbE-Port im Switch. Switche mit mehr 10GbE-Kupfer-Ports sind aber oft nicht lüfterlos, was schlecht ist, wenn der Switch nicht im Serverschrank oder im Keller steht.
Wenn doch Glasfaser, mit dem Mikrotik CRS305 gibt es einen günstigen managed Switch mit sfp+. Da kann man im Prinzip auch sogenannte Transceiver für 10GbE-rj45 reinstecken, aber dann ist er nicht mehr so günstig.
-
Ein 10Gbit Managed Switch ist gesetzt und verfügbar.
Optisch mit sfp+ oder Kupfer mit rj45?
Vorteil optisch mit Glasfaser: Preiswertere Switche und Einsteckkarten, keine Störungen durch Stromleitungen, größere Entfernungen und (in Zukunft) höhere Geschwindigkeiten, geringerer Stromverbrauch
Vorteil Kupfer mit rj45: PoE möglich, Kupferkabel möglicherweise schon verlegt, 2,5GbE als Zwischenschritt möglich.
Wenn der Switch mit sfp+ ist, weil optische Verbindungen angedacht sind, würde ich nicht zögern und gleich eine sfp+ Karte in das NAS einbauen. 2,5GbE als Zwischenschritt ist nur über rj45 möglich, was als sfp+ Transceiver zwar machbar, aber hier finanziell nicht attraktiv ist. Gebraucht gibt es Einsteckkarten mit ein oder zwei sfp+ Ports manchmal recht günstig; für das NAS sollte man aber eine Karte nehmen, die zumindest baugleich zu einer offiziell unterstützten Karte ist.
Wenn rj45 mit Kupfer, dann würde ich dies hier
Pragmatisch betrachtet würde ich wohl mit der bestehenden Hardware aka 2.5Gbit beginnen und dann bei Bedarf das NAS auf 10Gbit Steckkarte erweitern
machen. erst mal sehen, ob die real erreichten Geschwindigkeiten überhaupt an der Grenze von 2,5GbE kratzen. Eine 10GBit-Karte kann man sich später immer noch kaufen. Teurer werden die nicht.
Link Aggregation würde ich nicht in Erwägung ziehen. Ich hätte da so meine Zweifel, ob das mit WLAN dazwischen überhaupt (stabil) funktioniert.
