Storage der Nutzerdaten bei Gebrauch von Nextcloud Docker - auf der Suche nach Tips von erfahrenen Nutzern

[ullibelgie]

Guten Abend,

Ich habe inzwischen einige Erfahrungen gemacht mit einer urspünglich nur als Test gedachten Nextcloud Installation mittels Docker auf meinem Unraid Server. Es geht hier jetzt nicht um den Docker, sondern um ein möglichst effizientes System zum Speichern der Nutzerdaten.

 

In meine damals aufgesetzten Testinstallation (die auch heute noch so existiert) hatte ich den Folder der Nutzerdaten ausserhalb des appdata Folders auf dem Array installiert. Ich dachte mir damals, ja wenn jemand 1GB Video hochlädt, dann wird der (damals knapp bemessene) Cache sehr schnell voll sein und es können beim Family-server ja möglicherweise auch viele Daten anfallen.

Ausserdem wollte ich den Appdata Folder der Nextcloud nicht so "grenzenlos aufblähen", da mir nicht klar war, wie ich schnell und effizient Backups der Nutzerdaten und der Appdata der Nextcloud machen sollte...

 

Inzwischen ist mir aber auch klar, dass es die Nextcloud sehr verlangsamt, wenn beim hochladen der Daten die Files direkt auf das Array geschrieben werden müssen, weil der Data folder eben auf dem Array ist und nicht auf dem Cache, wo die appdata von dem Nextcloud Docker sich befindet.

 

Ich habe nur ein kleines Array von einer Platte und einer Parity

ausserdem 2x NVME als BTRFS mirror
 

Das uploaden sollte dann doch auf die NVMEs passieren, aber es sollte dann eben übertragen werden zur Sicherung auf das Array (parity).  Wie realisiere ich das am besten auf einfache Weise ?

Wie habt Ihr es gelöst um einerseits die NVMEs als schnellen Schreibcache in der Nextcloud zu nutzen und andererseits das Array als Massenspeicher ? Würde mir die Nextcloud app "external Storage" bei der realisierung helfen?

 

Danke für Hinweise, wie ich mich weiter schlau machen kann...

 

Hintergrund: In unserem lokalen Hobbyclub gibt es einige besondere Projekte, wo die Mitglieder viel miteinander kommunizieren mûssen um die Projekte zu realisieren. Es geht dann um ca 10-15 Personen, die mit verschiedensten Dokumenten und auch Meetings nach und nach zum Ziel kommen müssen. Ich dachte mir meine Nextcloud als Plattform im Hobbyclub anzubieten - online meetings sparen viel Zeit mit abendlichen Meetings irgendwo und man kann schnell in Kontakt mit anderen kommen.

Sind 10-15 Leute die intensiv zusammenarbeiten für meine einfache Installation auf Dockerbasis zu hoch gegriffen.

Natürlich muss ich ein vernünftiges Speicherkonzept finden, einerseits Schnelligkeit andererseits Sicherheit im Array (externe Backups selbstverständlich)

 

Fûr Tips und Hinweise bin ich dankbar.

[BernhardBerlin]

Hallo, 

 

das Problem hatte ich anfangs auch.

 

Mittlerweile „gute“ Performance habe ich aus zwei Ansätzen bekommen.

 

Array-Aufbau:

Ich nutze meine HDDs (2x16TB) ausschließlich für Backup und Daten die nicht häufig verwendet werden.

 

Einen SSD Data-Pool aus 4x2TB (RAIDz1) unter ZFS. Das hat Vorteile beim Stromverbrauch. ZFS bietet den Vorteil, dass du Snapshots erstellen kannst. Und du kannst eine einfache Backupstrategie aufbauen. Auf dem Pool liegen die Daten von: Immich (90k Fotos & Videos), Nextcloud, Paperless, SMB shares, etc

 

Einen NVME Pool für Appdata:

Auf dem Pool laufen dann alle Docker und VMs.

 

Nextcloud-Aufbau:

Ich nutze Nextcloud auf postgreSQL v12 in Kombination mit Redis. Außerdem habe ich Nextcloud „abgespeckt“ und alle nicht benötigten Apps gelöscht..

 

Über Cloudflare Tunnel und 2FA (Two Factor Authentification) ist Nextcloud erreichbar. 

Das System läuft auf einem AliExpress N305 Board bei 13-16W.
 

Ich hoffe, das gibt dir ein paar Ideen.

 

Edited September 21, 2024 by BernhardBerlin

[Archonw]

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.

[ullibelgie]

Vielen Dank für die Antworten bisher... das zeigt schonmal 2 Ansätze

@Archonw Ich nehme an, Du nutzt als Cache dann wohl xfs als Filesystem ? Denn ich hatte irgendwo gelesen, dass Marc's (mgutt) script nicht für ZFS gedacht ist. Bei ZFS wäre ja dann snapshot und replication mit einem Scipt wie spaceinvader das nutzt sinnvoller. Wenn ich das umsetzen würde ist muss ich auch die Ziel-Datenträger auf ZFS laufen lassen...

Ich wollte ZFS aber erstmal ausklammern, bis die Unraid Vers 7 stabil läuft und vor allem auch offiziell released ist.

 

Die Zwischenlösung ist dann wohl:

Den Nextcloud Data share, der sich bisher auf dem Array befindet rüberkopieren auf den Cache - Docker mapping entsprechend anpassen und dann die Backupstrategie so anpassen, dass der gesamte CacheDrive jede Nacht auf das Array gesichert wird.

[Archonw]

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.

[BernhardBerlin]

9 hours ago, ullibelgie said:

Wenn ich das umsetzen würde ist muss ich auch die Ziel-Datenträger auf ZFS laufen lassen...

Nicht zwingend. Du kannst es entweder über rsync local oder via ssh auf einen anderen Server syncen.

Bei mir zB laufen täglich ZFS Snapshots, nutze allerdings Duplicacy als Backuplösung.

[ullibelgie]

Ich bedanke mich bei Euch beiden...

Inzwischen habe ich den Daten Ordner auf den BTFRS Mirror cache übernommen und die Backup scripts entsprechend angepasst...

 

[mgutt]

Ich habe schlussendlich aufgegeben und mir eine 4TB SSD als Cache verbaut  😅

 

Mir ging das jedenfalls mega auf den Senkel, dass ständig das Array hochfuhr + die Wartezeit beim Zugriff auf Dateien. Und Nextcloud weckt auch gerne das Array ständig auf, weil es in die eine oder andere Datei von sich aus schreibt, wo man es evtl nicht erwartet.

 

 

Das anzeige was ich vom Array einbinde, sind handverlesene Shares als read-only external Storage. Das ist dann natürlich auch lahm, wenn mal jemand was davon braucht, aber das wissen dann alle und da lädt dann aber auch keiner was hoch.

 

[ullibelgie]

8 hours ago, mgutt said:

Mir ging das jedenfalls mega auf den Senkel, dass ständig das Array hochfuhr + die Wartezeit beim Zugriff auf Dateien.

Genau - das war mir auch aufgefallen. Nachdem ich aber den DATA ordner jetzt auf den NVME-ssd's habe schäft das Array.

Ob ich noch "external Storage" nötig habe werden wir sehen - bis jetzt war das nicht nötig. Ich gebrauche ja Nextcloud nicht um Media zu streamen...

[DocM]

Guten Abend zusammen,

 

habe jetzt schon einiges zum Thema NC auf unraid gelesen.

 

Verstanden habe ich, dass viele die User-Daten direkt auf den Cache legen und dann ggf. mit dem rsync-Script von @mgutt Backups erstellen.

 

Meine Frage bezieht sich eigentlich eher auf den Mover.... angenommen ich setze das DATA-dir von NC auf /mnt/user/XXX und nehme für XXX als Primary den Cache und als Secondary das Array. Kann ich dann dem Mover nicht sagen, dass er nur Dateien verschieben soll, die länger als z.B. 1 Monat nicht geöffnet wurden? 

Dann müsste doch (bitte korrigiert mich, wenn ich falsch liege) das Array nur hochfahren, wenn ich per NC auf Dateien zugreife, die ich seit z.B. 1 Monat nicht geöffnet hatte, oder?

 

Entschuldigt bitte meine Unwissenheit.. konnte diese Fragestellung trotz Forum und Doku noch nicht wirklich für mich klären 😞

 

Vielen Dank!

 

[mgutt]

23 minutes ago, DocM said:

Kann ich dann dem Mover nicht sagen, dass er nur Dateien verschieben soll, die länger als z.B. 1 Monat nicht geöffnet wurden? 

Das kann der Mover nicht. Man könnte höchstens selbst was skripten, dass man aktuelle Dateien 1:1 auf den Secondary kopiert. Wenn die Datei schon auf dem Secondary liegt, überspringt der Mover die Datei. 

[DocM]

Danke dir!

 

Schaue es mir morgen nochmal in Ruhe an.

 

Klingt aber fast so als sollte man den black friday nutzen um nochmal an ne x TB SSD zu kommen

 

[alturismo]

9 hours ago, DocM said:

Meine Frage bezieht sich eigentlich eher auf den Mover.... angenommen ich setze das DATA-dir von NC auf /mnt/user/XXX und nehme für XXX als Primary den Cache und als Secondary das Array. Kann ich dann dem Mover nicht sagen, dass er nur Dateien verschieben soll, die länger als z.B. 1 Monat nicht geöffnet wurden? 

 

schau dir mal das plugin an, die Funktionen sind beschrieben ... teste es aus ob das deinen Bedürfnissen entspricht ...