SSD Volume mit/ohne SSD Cache


Recommended Posts

Posted (edited)

Hallo zusammen,

 

ich habe hier 10 Stück 250GB SSDs "herumliegen" und frage mich vor meinen ersten Unraid Gehversuchen folgendes: Bringt ein SSD Cache aus z.b. 2 dieser SSD im Raidverbund vorgeschaltet vor den restlichen 8 SSDs (BTRFS mit 2 SSDs als Ausfallsicherheit) irgendeinen Vorteil oder kann ich mir den SSD Cache sparen?

 

Grüsse

Edited by nicx
Link to comment
1 hour ago, nicx said:

kann ich mir den SSD Cache sparen?

Du kannst einem Pool gar keinen Pool vorschalten, daher geht es selbst nicht, wenn du es wolltest. Aber auch bei einem Array wäre das tatsächlich überflüssig.

 

Aber warum überhaupt die SSDs im Pool und nicht im Array? Wäre mir klar zu viel Write Amplification durch BTRFS (erhöhte Abnutzung der SSDs) und die würden auch ständig im Betriebsmodus verbleiben, da man das komplette RAID seltenst in den Standby bekommt.

 

 

Link to comment
Posted (edited)

danke @mgutt, es scheint ich muss mich nochmals genauer mit den begrifflichkeiten auseinandersetzen, vor allem der unterschied zwischen array und pool :)

 

wenn ich dich aber richtig verstanden habe ist es unabhängig davon aus performancesicht irrelevant, ich kann einfach alle SSDs in einen Pool (oder Array?) stecken auch ohne Cache.

 

Wie gesagt: Die SSDs habe ich allesamt übrig für den neuen Unraid Server, daher möchte ich mit diesen das "beste" aus Geschwindigkeit/Haltbarkeit/NutzbareGröße/Ausfallsicherheit herausbekommen. Daher hötte ich bisher gedacht: Einfach alle zusammen in einen Pool und eben aus Ausfallsicherheit 2 Paritätsplatten. Thats it.

 

Hättest du mir einen langelbigeren/bessern Tip @mgutt? :)

 

EDIT: Ich hab gerade auch noch 2 Stück 3TB HDDs ausgekramt, die würden mit als reine Datenplatten ebenfalls ausreichen (also 3TB insgesamt). Wichtig: Das Betriebssystem, Die ganzen Applikationen und Docker-Container möchte ich gerne hochperformant haben, also eher auf den SSDs laufen haben. Hintergrund: Bisher habe ich auf einer Synology Diskstation die Erfahrung gemacht dass normale HDDs Anwendungen wie z.b. Datenbanken und auch die Docker Container allesamt zu sehr ausbremsen.

 

Gibts mit dieser neuen Info bzgl. Vorhandensein der HDDs eine andere Empfehlung bzgl. Pool-Konfiguration?

Edited by nicx
Link to comment
Posted (edited)
38 minutes ago, nicx said:

Das Betriebssystem, Die ganzen Applikationen und Docker-Container möchte ich gerne hochperformant haben, also eher auf den SSDs laufen haben.

Das Betriebssystem (unRaid) lässt sich ausschließlich von einem USB-Stick booten, und läuft anschließend komplett im RAM. Es gibt keine Möglichkeit der Installation auf eine SSD (oder HDD).

VM's und Docker jedoch sollten auf den Cache. Seit 6.9 hat man die Möglichkeit mehrere Cache-Pools zu erstellen. Kannst also z.B. einen Pool den VM's zuweisen, einen den Docker Containern und einen weiteren als Cache für die Array-Daten. Nur ein Beispiel...

 

38 minutes ago, nicx said:

Gibts mit dieser neuen Info bzgl. Vorhandensein der HDDs eine andere Empfehlung bzgl. Pool-Konfiguration?

Wenn die 3TB für Dich ausreichen, dann nimm die beiden HDD's und erstelle mit denen das Array (1x Parity 3TB und einmal Daten 3TB).

Edited by saber1
Link to comment

danke @saber1, jetzt hast du mich allerdings etwas verwirrt, da du nun von einem Cache sprichst, auf den ich die Docker Container laufen lassen soll. Ein "Cache" ist meinem Verständnis nach aber immer nur ein "unsichtbarer" vor einem langsamerem Speicherplatz vorgeschalteter schnellerer Speicherplatz, auf de:man eben nicht direkt zugreifen kann für Installationen von Applikationen, sondern der nur zur Beschleunigung genutzt wird.

 

Das Betriebssystem läuft immer im Ram, das habe ich verstanden, so weit, so gut :)

 

Welche konkrete Empfehlung für die Aufteilung der Platten gibt es denn nun in meinem Fall? Wie gesagt, ich habe insgesamt 10 SSDs mit je 250GB und 2 SATA HDDs mit je 3TB. An Speicherplatz für Daten (Dokumente, Fotos, etc.) benötige ca. 1.5 TB. Eine externe Backup USB-HDD mit 2TB ist ebenfalls vorhanden. Ansonsten ist mir wichtig das alle Docker Container (Datenbanken, Home Assistant, etc.) hochperformant laufen, auch z.b. Indizierung von Fotos (Nextcloud). 

 

 

Link to comment
3 minutes ago, nicx said:

Ein "Cache" ist meinem Verständnis nach aber immer nur ein "unsichtbarer" vor einem langsamerem Speicherplatz vorgeschalteter schnellerer Speicherplatz

Bei Unraid nicht. Dort ist er ein separates Volume, dessen Inhalt du sehen kannst. Siehe auch:

https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-951565

 

 

Vom Prinzip steht dir jede Variante offen. Du könntest ein reines SSD Array machen und gar keine Pools nutzen. Du könntest ein HDD Array machen und einen SSD RAID Pool (Cache) davor schalten. Oder du könntest sogar HDDs ins Array, SSD Pool als Cache davor und noch einen separaten SSD Pool für andere Daten erstellen.

 

Ohne HDDs wäre der Server sehr stromsparend und durchgehend performant, aber du bräuchtest für die 10 SSDs 10 SATA Ports, was nur mit einem zusätzlichem SATA Controller möglich wäre, der auch wieder Strom verbraucht. Oder du lebst mit 7x SSD + 1x Parität und sicherst per USB auf eine HDD. Dann ginge ein Board mit 8x SATA. Mit der Zeit könntest du dann ja größere SSDs nachrüsten und damit evtl wieder SATA Ports freischaufeln.

 

Wenn dir Backups reichen, könnte man sogar komplett ohne Parität arbeiten. Möglichkeiten gibt es also genug.

Link to comment
21 minutes ago, nicx said:

Ein "Cache" ist meinem Verständnis nach aber immer nur ein "unsichtbarer" vor einem langsamerem Speicherplatz vorgeschalteter schnellerer Speicherplatz

Sieh dir dieses bild mal an:

Unraid-array-with-cache.gif.bc4a99b9c986d6801e98971bb0054b8f.gif

 

Und hier der zugehöroge link zur erklärung: Klick

Link to comment

ok so langsam wirds hell, dnke euch für eure ausführungen :)

 

bezüglich sata ports ist das für mich kein problem, da die hardware bereits vorhanden ist inkl. erweiterungs-sata-karte. im grunde habe ich alles schon "rumliegen" und keine hw kosten ;)

 

ich würde nun folgende aufteilung versuchen, da ich so sowohl performanz als auch mehrstufiges backup hätte:

 

1 array aus 10x 250gb ssd (2 davon für parität) -> alle daten

1 array mit 1x 3tb hdd (ohne parität) -> z.b. stündliche backups

1 usb 3tb hdd -> regelmässige (alle paar wochen) auslagerungs-backups (nach backup ende wird die usb hd in einem anderen raum gelagert)

zusätzlich würde ich noch täglich ein verschlüsseltes backup in "die cloud" machen, z.b. auf ein bestehenden ms account mit 1tb onedrive platz (bisher ungenutzt)

 

wie ist euer feedback dazu? :)

 

Link to comment
31 minutes ago, nicx said:

1 array aus 10x 250gb ssd (2 davon für parität) -> alle daten

1 array mit 1x 3tb hdd (ohne parität) -> z.b. stündliche backups

1 usb 3tb hdd -> regelmässige (alle paar wochen) auslagerungs-backups (nach backup ende wird die usb hd in einem anderen raum gelagert)

Du kannst momentan nur ein Parity geschütztes Array in Unraid erstellen, was du aber machen kannst ist das du dir mehrere Cache pools anlegst (ein Cache pool kann auch nur eine Festplatte sein) oder du dir das Plugin Unassigned Devices installierst und die Festplatte dort einbindest (wenn es denn nur eine einzelne ist).

 

Sprich:

  • Das Array aus 10x 250gb und 2x für Parität würde funktionieren (bedenke jedoch das SSD's im Array nicht empfohlen werden da man nicht immer weiß wie die mit den leeren Sektoren umgehen und ob der controller darauf nicht irgendetwas umsortiert intern, das wäre für die Parität nicht so toll).
  • Ein Cache Pool für deine Stündlichen Backups (den du nicht zum beschleunigen zum schreiben auf das Array verwendest wie oben beschrieben sondern nur für deine Stündlichen Backups).
  • Die USB 3.0 Festplatte würde ich dann in Unassigned Devices einbinden, dort kannst du auch beispielsweise ein skript ausführen lassen kannst wenn diese angeschlossen wird. :)

 

Ich glaub in deinem Fall kannst du den Cache wie er auf Unraid normalerweise funktioniert dann weglassen wenn du ein Array nur aus SSD's verwendest (musst aber ggf. den Reconstruction Mode an machen).

 

Meines Wissens hat @giganode auch ein Array aus nur SSD's, vielleicht kann er hier ja mal seinen Senf dazugeben wenn er Zeit hat (viel beschäftigter Mann :D ).

 

31 minutes ago, nicx said:

bezüglich sata ports ist das für mich kein problem, da die hardware bereits vorhanden ist inkl. erweiterungs-sata-karte

Was für Karten sind das denn? Bedenke mit einem Array aus nur SSD's werden ältere Controllerkarten an den Rand der Belastbarkeit getrieben und du erhältst evtl. nicht die volle Geschwindigkeit...

Link to comment

ah ok, das mit unraid nur genau 1 array möglich macht meinen plan wieder zunichte, danke für den hinweis. dann würde ich wahrscheinlich dazu tendieren sowohl die einzelne interne 3tb sata hd als auch die usb haüd über das plugin unassigned devices zu integrieren. klingt für mich erst einmal einfacher als den cache pool workaround zu gehen, bei cache denkt mein hirn immer an schnellen speicher was ja in meinem fall nicht passen würde :D

 

diese sata controller habe ich im einsatz: https://www.amazon.de/dp/B07PJFZRRW/ref=pe_3044161_185740101_TE_item, zumindest bisher habe ich dabei keine probleme bemerkt. ich habe aber ehrlicherweise auch nicht direkt danach gesucht ;)

 

 

Link to comment
9 hours ago, nicx said:

diese sata controller habe ich im einsatz

Es gibt bei manchen Marvell Controllern Probleme in Sachen VMs, aber sonst sollte der gehen:

https://forums.unraid.net/topic/39003-marvell-disk-controller-chipsets-and-virtualization/?tab=comments#comment-380258

 

 

9 hours ago, ich777 said:

Meines Wissens hat @giganode auch ein Array aus nur SSD's, vielleicht kann er hier ja mal seinen Senf dazugeben wenn er Zeit hat (viel beschäftigter Mann :D ).

Drei meiner Kunden betreiben Unraid SSD only. Es gibt keinen außer JorgeB, der jemals von Problemen berichtet hat und das betraf ein bestimmtes SSD Modell. Vom Prinzip ist es simpel. Dateien drauf, ein paar wieder löschen und dann einen Parity Check machen. Solange der fehlerfrei läuft, sind die SSDs geeignet.

 

 

  • Thanks 1
Link to comment
9 hours ago, nicx said:

diese sata controller habe ich im einsatz: https://www.amazon.de/dp/B07PJFZRRW/ref=pe_3044161_185740101_TE_item, zumindest bisher habe ich dabei keine probleme bemerkt. ich habe aber ehrlicherweise auch nicht direkt danach gesucht

Sieh dir mal diese Tabelle an (Source😞

grafik.thumb.png.ced20b60e5078eb6b0c763fad0da783f.png

 

Du hast hier ein PCIe x1 interface und wenn das stimmt was auf der Karte steht dann in Version 3.0 du kannst also einen maximalen theoretischen Druchsatz von 0.985GB/s haben sprich du würdest dann theoretisch schon am Limit sein wenn du auf 2 SATA SSD's schreibst bzw. liest (mit einer durchschnittlichen Geschwindigkeit pro SSD von 492,50MB/s gerechnet).

Wenn du auf das Array schreiben würdest, wie in deinem geplanten Setup, schreibst du gleichzeitig immer auf 3 SSD's (2 Parity und die Datenplatte) sprich du könntest somit nicht die maximale Geschwindigkeit der SSD's ausnutzen und hättest pro SSD dann "nur" einen maximalen Durchsatz von 328,33MB/s (bitte vergiss nicht wenn da noch eine andere Platte drauf hängt und die auch grad was schreibt dann müsstest du das nochmal teilen).

 

Hoffe das ergibt Sinn für dich (und ich hoffe ich hab mich nicht verrechnet... :D ).

 

21 minutes ago, mgutt said:

aber sonst sollte der gehen

Ja der funktioniert, hat ein Kumpel von mir mit normalen Festplatten (HDD's) am laufen.

Link to comment
56 minutes ago, ich777 said:

 

Du hast hier ein PCIe x1 interface und wenn das stimmt was auf der Karte steht dann in Version 3.0 du kannst also einen maximalen theoretischen Druchsatz von 0.985GB/s haben sprich du würdest dann theoretisch schon am Limit sein wenn du auf 2 SATA SSD's schreibst bzw. liest (mit einer durchschnittlichen Geschwindigkeit pro SSD von 492,50MB/s gerechnet).

Wenn du auf das Array schreiben würdest, wie in deinem geplanten Setup, schreibst du gleichzeitig immer auf 3 SSD's (2 Parity und die Datenplatte) sprich du könntest somit nicht die maximale Geschwindigkeit der SSD's ausnutzen und hättest pro SSD dann "nur" einen maximalen Durchsatz von 328,33MB/s (bitte vergiss nicht wenn da noch eine andere Platte drauf hängt und die auch grad was schreibt dann müsstest du das nochmal teilen).

@nicx hast Du über das Netzwerk denn auch die Möglichkeit diese Performance zu nutzen, denn mit einem 1Gbps Ethernet bist Du auf etwa 112MB/s limitiert?

Für VMs/Docker würde ich auch ein SSD Array nicht einsetzen. Da ist ein Cache Pool günstiger, auch vom Verschleiss.

  • Thanks 1
Link to comment
4 hours ago, Ford Prefect said:

Für VMs/Docker würde ich auch ein SSD Array nicht einsetzen. Da ist ein Cache Pool günstiger, auch vom Verschleiss.

Der Pool ist BTRFS formatiert und BTRFS besitzt die höchste Write-Amplification überhaupt. Der Verschleiß ist also im Array viel geringer und nicht höher. Das Array bietet dazu ein Feature, worauf Synology beim RAID F1 ganz stolz ist, nämlich, dass die Parität stärker abgenutzt wird als die restlichen SSDs. Auf die Art sinkt die Wahrscheinlichkeit, dass einem zwei SSDs zur selben Zeit ausfallen.

 

 

4 hours ago, Ford Prefect said:

hast Du über das Netzwerk denn auch die Möglichkeit diese Performance zu nutzen

Er will ja Docker/VM drauf laufen lassen. Daher nutzt er sie auf jeden Fall. Alleine der Parity-Rebuild / Check geht mindestens doppelt so schnell. Auch nicht verkehrt. Wenn ich könnte, würde ich sofort auf SSDs umschwenken. Egal ob 1G oder 10G Netzwerk. 

 

Link to comment
1 hour ago, mgutt said:

Der Pool ist BTRFS formatiert und BTRFS besitzt die höchste Write-Amplification überhaupt. Der Verschleiß ist also im Array viel geringer und nicht höher. Das Array bietet dazu ein Feature, worauf Synology beim RAID F1 ganz stolz ist, nämlich, dass die Parität stärker abgenutzt wird als die restlichen SSDs. Auf die Art sinkt die Wahrscheinlichkeit, dass einem zwei SSDs zur selben Zeit ausfallen.

...interessant, allerdings sehe ich das trotzdem nicht so ganz.

Eine vDisk-Datei einer VM wird die Daten- und beide Parity belasten.

Eine zweite VM eine weitere Daten-Disk und die beiden Parity dazu, die dann eben für beide vDisks den Verschleiss haben.

Da sehe ich keinen Unterschied zum Verschleiss eines Pools.

Ein Pool für mehr als eine VM, also dann auch grössere SSDs bedeutet in der Regel höhere TBW (und mehr Over-Provisioning) und höhere IOPS.

 

...meine Strategie wäre daher nach wie vor Cache-Pool, wenn ich paranoid bin tripple Mirror, mit SSDs hoher TBW und Backup.

Das BTRFS da einen negativen Effekt hat nehme ich in Kauf, solange kein ZFS wirklich verfügbar ist.

Soweit ich auch weiss, gibt es TRIM Support auch nur im Pool und nicht auf dem Array...können alle SSDs inzwischen sowas wie Auto-Trim und würde das auf einer Parity überhaupt funktionieren?

 

So ein SSD-only System ist schon speziell und das bessere ist der Feind des Guten.

Daher würde ich dann eher doch mit einem napp-it oder Proxmox bauen um ZFS snaps zu bekommen und auch um mich nicht mit der Performance nur einer Disk zufriedengeben zu müssen....wenn schon, denn schon...aber das gehört dann nicht hierher.

Link to comment
8 minutes ago, Ford Prefect said:

So ein SSD-only System ist schon speziell und das bessere ist der Feind des Guten.

Mal was ganz anderes zwischendurch:

 

Mich würd interessieren wie sich ein Array verhält das auch 1 oder 2 Parity SSD's (da die ja mal günstig waren auch in größeren Kapazitäten - aber dann kam Chia... :( ) besteht und der rest aus HDD's.

Speziell würde mich interessieren ob ein schnelleres schreiben möglich ist wenn die Paritys SSD's sind...

Link to comment

..das Problem ist, das eine 250GB HDD schon ein Methusalem ist ;-)

Ich würde vermuten, dass man nah an die Performance einer HDD rankommt, da Seitens Parität der "angesprungene" Block bei einer SSD "sofort" verfügbar ist.

Es wird aber Overhead geben, da der Standard Linux-Kernel an sich ja nicht Realtime-fähig ist und evtl. selbst bei zu kurzen Antwortzeiten aus dem Tritt kommt.

Das Phänomen gab es schon bei PCIe-RAM Disks, vor 15 Jahren oder so...der Chipsatz kommt nicht mit.

Link to comment
59 minutes ago, ich777 said:

Speziell würde mich interessieren ob ein schnelleres schreiben möglich ist wenn die Paritys SSD's sind...

Ja ist es. Ich hatte ja schon eine schnellere HDD als Parität. Das wirkt sich direkt aus. Und SSDs kommen ohne Turbo-Write beim parallelen Lesen und Schreiben auf ca 170 MB/s. Mit Turbo Write wären wieder die HDDs im Array der Flaschenhals. Und SSD Only kam ich mit 4 SSDs problemlos auf über 500 MB/s (mit Turbo-Write):

 

1758358574_2021-05-1911_20_12.png.827ea4e9eea63d8248b82ed78e359cdd.png

 

2094023955_2021-05-1911_18_34.thumb.png.3dde82ac95ac53900a7000d8645f3002.png

 

 

1 hour ago, Ford Prefect said:

Eine vDisk-Datei einer VM wird die Daten- und beide Parity belasten.

Eine zweite VM eine weitere Daten-Disk und die beiden Parity dazu, die dann eben für beide vDisks den Verschleiss haben.

 

Gehen wir mal praktisch vor. 5 SSDs mit jeweils 1TB.

 

RAID6:

Wir machen den Pool voll, also fügen 3TB an Daten hinzu. Abgenutzt wurden 5TB, da 2x 1TB für die Parität draufgehen. Diese Schreibvorgänge wurden gleichmäßig verteilt. Alle 5 SSDs haben sich also um 1TB abgenutzt.

 

Array mit 2x Parity:

Wir machen das Array voll, also fügen 3TB an Daten hinzu. Bei jedem 1TB wechselt die Disk und die Paritäten werden von vorne neu geändert. Also werden für jedes 1TB zusätzlich 2x 1TB an Paritäten korrigiert. Die Paritäten haben sich also um jeweils um 3TB abgenutzt und die Daten SSDs um jeweils 1TB. Macht insgesamt 9TB, statt nur 5TB.

 

Also stimmt deine Aussage. Das Array nutzt die SSDs mehr ab. Allerdings haben wir da noch die bis zu 30-fache Write Amplification von BTRFS. Die ist ja der Hauptgrund dafür, dass sich viele über die Abnutzung ihrer SSDs beschweren.

 

Was ist nun besser?! 🤔 🤷‍♂️

  • Thanks 2
Link to comment
22 hours ago, ich777 said:

Meines Wissens hat @giganode auch ein Array aus nur SSD's, vielleicht kann er hier ja mal seinen Senf dazugeben wenn er Zeit hat (viel beschäftigter Mann :D ).

Nimmst mich schon wieder auf die Schippe?! :D 

 

Ja, ich habe keine einzige drehende Platte in meinem Server und bin total zufrieden so. Nicht einen einzigen hardwarebedingten Fehler im Array kann ich bisher vorweisen.

 

Mein Array besteht aus WD Red SSDs. Appdata und docker liegen auf einem cache pool, damit wie er selbst schon sagte Datenbanken nicht gebremst werden und um Energie zu sparen. 2 NVMes brauchen weniger Saft als mein Array mit dem zugehörigen hba. Die vDisks meiner VMs liegen auf einer weiteren NVMe.

 

  • Haha 1
Link to comment
35 minutes ago, giganode said:

und um Energie zu sparen

Wenn die DB zb auf Disk 3 liegt, dann läuft auch nur Disk 3 beim Lesen und eben die Parity beim Schreiben. Sie gehen dann super schnell in den Leerlauf (von sich aus). Alle anderen Disks sind dann eh im Leerlauf. Wenn du dagegen zb drei SSDs im RAID hast, laufen immer alle beim lesen und schreiben. Also von der Effizienz her sollte das Array im Vorteil sein.

 

Das mit dem HBA verstehe ich nicht. Der ist doch sowieso immer an?!

Link to comment
23 hours ago, mgutt said:

Das mit dem HBA verstehe ich nicht. Der ist doch sowieso immer an?!

 

Ja klar ist der immer an, aber hba's brauchen ja nicht immer gleich viel.. Genau wie cpus oder gpus können die ja auch unter Volllast laufen oder fröhlich vor sich hin idlen.

Link to comment

Erst einmal vielen Dank für eure Tips und auch die spannende Diskussionen :) Ich habe mich nun für folgende Vorgehensweise entschieden:

 

* Austausch des SATA-Controllers auf einen ASMedia ASM1166

* Erstellung eines SSD-Only Arrays mit 6 250GB SSDs für Daten und 2 Parität-SSDs (2 SSDs habe ich dann zusätzlich übrig, die baue ich aber erst einmal nicht ein da ich die Datenmenge nicht brauche)

* Keinen Cache-Pool

* 2-stündliche Backups auf interne 3TB SATA HDD (über "Unassigned Devices")

* Tägliche Auslagerungs-Backups auf externe 3TB USB HDD (über "Unassigned Devices")

 

Passt das so aus eurer Profi-Sicht? :)

 

Einzige Frage die ich mir noch stelle: Soll ich das Array XFS oder BTRFS formatieren? (BTRFS-)Snapshots brauche ich mit obigem Backup-Konzept ja nicht wirklich.

 

 

Link to comment

So mein Unraid Server läuft und ich bin echt begeistert. Hätte ehrlicherweise nicht gedacht dass alles so smooth einzurichten geht, und die Community ist dazu wirklich grossartig :)

 

Mein Testaufbau mit 3 SSDs und 20 Docker Container läuft, alles ist super schnell, im Array ist schön zu sehen das lediglich die Parity-SSD und 1 Daten-SSD "belastet" wird, die zweite SSDs hat nichts zu tun (solange die Datenmenge natürlich nicht anwächst und die Kappa einer SSD überschreitet). Ich denke das ist wirklich so SSD-schonend wie möglich.

 

Eine Frage noch, zwar eher nicht direkt zum Thema passend, aber zumindest ein wenig "speicher-relevant": Ist es empfehlenswert alle Docker-Mounts für Persistance Data grundsätzlich direkt nach appdata zu mounten oder eventuell auf einen eigenen Share? Mir gehts vor allem um die Userdaten hier, und das Handling dieser beim Backup/Restore, vor allem bei "grösseren" Containern wie Mailserver und Nextcloud.

 

Konkretes Beispiel: Ich habe einen Mailserver-Docker installiert und frage mich ob ich die User Maildirs auf /mnt/appdata/mailserver-docker/maildata belasse oder auf einen eigenen Share z.b. /mnt/user/mail lege?!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.