Archonw

Ich kann dir dafür auch nur Mgutt's Backup Script empfehlen. Einfach simpel und zuverlässig.

@unraid.techniker du hast lediglich einen Schreibfehler drin. Nimm: PAPERLESS_CONSUMER_ENABLE_BARCODES

Hi, Das war auch nur als Hinweis gemeint. Ist halt ein Fallstrick dem der eine oder andere schon zum Opfer gefallen ist. Wenn man das Ordentlich trennt, dann klar passiert das nicht. Daten die schon auf dem Array liegen nochmal in einen extra Backup Ordner zu packen kann sinnvoll sein, wenn man z.b. eine Versionierung wünscht, oder es gegen versehentliches Löschen helfen soll. Ein vollwertiges Backup sollte es aber nicht auf dem selber Festplatte liegen. Denn da nützt es nichts, wenn die Plattte einen defekt hat.

Ist das Array durch eine Parität geschützt? Denn dann sind das normale Werte. Um schnell auf einen Share schreiben zu können gibt es den Cache.

Ich würde zwar grundsätzlich raten ein Linux Dateisystem zu nehmen, um Sicherungen von Linuxsystemen zu machen, aber wenn ich das bei Duplicati richtig sehe, werden sie Dateien der Sicherung eh in ein eigenes Archiv Format gepackt, so dass man in den Einstellungen zur Sicherung nur die entsprechenden Haken setzen muss, damit auch die Dateirechte erhalten bleiben. Die Platte solltest du aber nicht ins Array aufnehmen. Bzw. wenn es bei ntfs bleiben soll ginge das ohne hin nicht. Und andererseits willst du ja eine Sicherung machen von Dateien, welche wahrscheinlich eh schon auf dem Array liegen, da würdest du dann nur waherscheinlich in einer Endlosschleife landen. Daher die Backup Platte als unassigend Device betreiben.

Meine Empfehlung, wenn der Cache im Single Mode betrieben wird, dann XFS wie auch das Array. Hintergrund: es sind viele User hier mit Problemen die durch BTRFS entstanden. Wird im Cache ein Stripe oder Mirror benutzt rate ich dann zu ZFS.

Du kannst daür Minidlna nehmen, Damit ist ein durchsuchen der Median anhand der Ordnerstruktur möglich.

Damir der Mover Daten verschiebt muss gewährleistet sein, dass keine Zugriff auf diese Daten erfolgt. Um jetzt appdata und system komplett erfolgreich verschieben zu können am besten den Docker Dienst dafür deaktivieren. Dann sollte der Mover alle Dateien verschieben können.

Whon hast du jetzt den Port 80 und 443 weitergeleitet? Die sollten auf den Nginx Proxy Manager zeigen. Nicht auf Wordpress direkt.

Das Problem kann halt wieder auftreten. Wodurch auch immer es erstmals ausgelöst wurde. BTRFS war bei mir z.b. anfällig bei Stromausfall. Wie gesagt, etliche Foreneinträge haben BTRFS zum Thema. Ich kann dir also nur raten stelle den Cache auf xfs um.

Ich bin leider auch mit BTRFS im Cache auf die Nase gefallen. Ja es gibt durchaus welche, bei denen das wunderbar läuft. Auch bei mit auf meinem Latop macht BTRFS keine Probleme. Dennoch wie @DataCollector schon erwähnte rate ich auch bei Single Cache Drives sehr zu xfs. Sämtliche Versuche seinerseits als ich ähnliches bei meinem BTRFS Cache hatte halfen keine der auffindbaren Reparuterhilfen zu BTRFS.

Womit lässt du dir denn deine SSL Zertifikate ausstellen? Welchen Reverse Proxy benutzt du?

Ist zwar keine direkte Lösung, sondern eher ein Ersatz: Ich benutze für den HA Zugriff einfach eine Wiregaurd Verbindung ins heimische Netz. Ich finde ein HA muss nicht ins öffentliche Netz.

Ich wüsste nicht, dass Unraid so etwas integriert hat. AD ist ja auch ein Windows Werkzeug. Daher denke ich wenn musst du den Weg über den Virtual DSM gehen.

Wenn der Mover benutzt wird sind nur dann Daten "doppelt" bzw. auf dem Cache und dem Array vorhanden, wenn man die Einstellungen wie alturismo yeigte aktivert. Wie zu lesen ist, werden aber dabei alle Veränderungen und auch das Auslesen der Daten vom Cache aus geregelt. Es ist also nur eine Backup-Kopie auf dem Array vorhanden. Ist der Mover ohen diese Einstellung aktivert liegen die Daten niemals doppelt vor. Also entweder liegt eine Datei noch auf dem Cache oder auf dem Array. Der Mover bewegt dabei nur Daten, auf die gerade nicht zugegriffen wird. Ist also eine Datei aktuell in verwendung wird diese vom Mover nicht angefasst.