Archonw

Um eine Backup von einem Docker anzulegen musst du alles an Orndern auf deinem Unraid sichern, in denen sich Daten dazu finden. Dazu gehört zum einen schon mal der Ordner appdata. Hier liegen im Normalfall die Konfihurationsdaten des Dockers. Also das was deine Installation ausmacht. Dann braucht man noch all jene anderen Ordner, die eventuell im Template hinterlegt sind. Und dann ist das Template selbt auch nicht schlecht, wenn das gesichert wird. So ist eine Wiederherstellung dann in Sekunden erledigt. Wenn ein Docker, wie Paperless noch weiter Docker benötigt um zu laufen, wie eine Redis Datenbank muss dafür dann natürlich das selbe passieren. Bei mir sieht das also so aus, dass ich den Ordner appdata komplett sicher und dazu all meine Share paperless in dem all die Dokumente von Paperless liegen. Redis hat seine Daten dabei bei mir ausschliesslich im appdata-Ordner.

Ich halte es wie @alturismo. Bin auch für Single drive mit xfs. Wenn es ein stripe oder ein mirror sein muss dann auch lieber mit zfs anstatt mit btrfs. Im privaten Bereich sehe ich den Mehrwert einfach nicht, den ZFS bieten soll. Da will ich lieber möglichst wenig Hürden zwischen mir und meinen Datenn. Als Sicherheit reicht mir dann lieber ein tägliches Backup meines Caches.

Ich hätte jetzt auf jeden Fall rsync empfohlen. Welchen Fehler gibt rsync aus, und kannst du dein rsync commando mal schreiben?

Ich bin auch noch nicht von ZFS überzeugt. Auch weil ich derzeit nur mit 16GB unterwegs bin und ZFS RAM intensiver ist. Meine Platten laufen alle, sowohl Cache als auch Array, mit XFS. Um deinen Data Share von Array auf den Cache zu bekommen musst du deine Share Einstellungen anpassen. Aus Cache only bzw Primary auf Cache und den Mover auf Array-Cahe stellen. Dann einmal den Nextcloud Docker und die Datenbank aus und den Mover starten. Wenn der durch ist kann wieder alles gestartet werden.

Hallo, Damit die Nextcloud flott läuft halte ich sowohl das appadata Verzeichnis als auch das User Daten Verzeichnis rein auf dem Cache. Ich selber nutze keinen Mirror, sondern Single Drive, und sichere jeden Abend meinen kompletten Cache auf das Array. Dafür nutze ich das Backup Script von Mgutt hier aus dem Forum. Damit werden platzsparende inkrementelle Backups angelegt. Einmal die Woche geht dann noch eine Sicherung des Arrays auf eine externe Festplatte. Ich würde dir auch empfehlen kein BTRFS Mirror zu nehmen, da hier schon viele Probleme mit BTRFS hatten mich eingeschlossen. Ja es gibt auch genug die seid Jahren problemlos dir arbeiten, doch wenn es zum Glücksspiel wird ist es eben nichts für einen produktiveinsatz. Wenn Mirror dann lieber auf ZFS umstellen. Nur bitte dann nicht alleinig auf Snapshots setzen bei der Backup-Strategie. Snapshots sind gut für die Versionierung aber nicht fürs Backup. Genau wie RAID kein Backup ist ist es auch bei Snapshots. Nur "richtige" Kopien zählen, wenn es um Backups geht. Das nur am Rande erwähnt. Ich würde wenn ZFS aber auf Stripe setzen somit größeren Cache erhalten und tägliches Backup aufs Array. Im Falle eines Ausfalls ist die Downtime die Länge die es braucht eine neue Platte zu besorgen und das Backup zurück zu spielen. Im privaten Bereich halte ich das für die sinnvollere Variante.

Damit das Array erfolgreich in den spin down geht, gehören einige Shares auf den Cache ausgelagert. Z.B. appdata, domain, system. Und wenn eine Nextcloud auch auch der Share mit den User-Daten. Dann klappt das mit dem Schlafengehen des Arrays.

Noch gibt es da nichts in den Einstellungen dafür.

Maybe you can recreate this with: occ recognize:recrawl

Ein Schuss ins blaue. Hast du eventuell irgendwelche der Shares in der Nextcloud verfügbar gemacht?

Bei einzelnen Platten bitte XFS.

Da die Platten nicht gleich groß sind, geht das auf dem Wege meines wissens eh nicht. Das Konstrukt der Parität ist das was Unraid ausmacht. Wenn man das (mit reinen HDD's) nicht nutzen will sollte man nochmal nach anderen NAS Software ausschau halten. Eventuell ist dann Unraid nicht das richtige.

Wie schon erwähnt ist ab der 7er Version kein Raid mehr zwingend notwendig. Doch die Absicherung der Daten gegen einen Ausfall mit Parität gibt es nur im Array. Will man kein Array benutzen, aber dennoch eine erste Hilfe gegen einen Ausfall haben muss man im Pool zu einem Mirror greifen. Sei es dann mittels BTRFS oder ZFS als Dateisystem. Empfehle dann aber lieber ZFS. Jetzt musst du dir die Frage stellen was an Daten werde ich haben, wie schnell müssen diese Abgelegt werden können, und wie oft greife ich auf diese Daten wieder zu. Und wie wichtig sind diese, bzw wie wenig darf diesen passieren. Davon hängt dann z.b. ab, ob man die Daten die auf dem Cache Laufwerk liegen absichern muss durch einen Mirror-Betrieb, da diese ja nicht von der Parität abgesicher werden. Also brauche ich einen Cache aus zwei gleich großen Laufwerken, um sie so spiegeln zu können, oder kann ich auch zwei getrennte Cache's damit betreiben. Ich stimme da DataCollector zu, dass man privat eher wenig Notwendigkeiten hat für einen gespiegelten Cache. Da reicht ein mitunter tägliches Backup um die Notwendige Datensichherheit zu gewährleisten. So würde man im Falle des Ausfalls des Cache-Laufwerkes "nur" die Daten eines Tages verlieren. Im privaten Bereich ist das eher kein Problem. Man kann die Daten meist recht einfach wieder besorgen. Daher rate ich dir auch, deine 2 NVME aufzuteilen in zwei getrennte Pools. So kannst du die eine z.B. als reinen Schreibcache für deine Video-Aufnahmen benutzen.(der MOver kann dann in der Nacht oder einen anderen passenden inaktiven Zeit diese Daten dann auf dein Array packen. So bleiben deine HDDS schlafen und werden nur kurz für den Kopiervorgang aufgeweckt.) Auf der anderen kannst du dann z.b. das Docker-image und VM Images ablegen, und so diesen auch einen eigenen Geschwindgkeitsboost verschaffen. Bleibt noch das Array. Da kommen alle weiteren HDD's rein mit der größten als Parität. Wollte man auf eine Absicherung durch die Parität verzichten sollte man vielleicht sich nochmal genauer umschauen, ob Unraid wirklich dem eigenem Nutzen entspricht.

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.