Hallo! Mal wieder ein NAS Thread... aber das Thema ist auch beliebig komplex... Mein 7 Jahre alte Synology NAS muss bald in Rente gechickt werden. Da ich in der Zwischenzeit mit meinen Clients auf Linux gewechselt bin und sich hier eine kleine Raspberry "Serverfarm" angesammelt hat, dachte ich, baue ich mir lieber was eigenständiges - und weiß dann am Ende hoffentlich Bescheid darüber ;) Die ganzen Funktionen die man von Synology/QNAP oder so bekommt, brauche ich eigentlich gar nicht und die paar, die ich brauche, würde ich am liebsten selbst basteln. Ich schieb das ganze schon vor mir her, da ich nicht so der Hardware typ bin. Ich dachte für die Hardware nehme ich mir einen Bauvorschlag, z.b. von der c't oder von anderen NAS Blogs. Was mir gerade erstmal mehr Sorgen bereitet ist die Software sache. Ich habe eigentlich nicht so viel Zeit, dass ich groß rumexperimentieren kann, daher möchte ich es am liebsten direkt richtig machen. Vielleicht mal kurz ein Überblick was ich mir vorgestellt habe: Ein Host System mit genug Plattenspeicher, CPU und RAM. Das Host System kann ja auf einer kleinen bis mittleren SSD laufen. Dachte an UbuntuServer oder an ein Debian. Auf dem Host System bräucht eich dann ca. 4 VMs 1. NAS VM, die soll Fileserver, ggf. DLNA und ein Fotoalbum bereitstellen Momentan habe ich 2TB Speicherplatz mit 2*2TB im RAID 1 (Synoloy), ich würde wenigstens gerne verdreifachen um Zukunftssicherheit zu haben. Würde liebend gerne mehr Backups der Clients auf dem NAS speichern. 2. NextCloud für die wichtigsten Dateien, Kalender und Kontakte Das kann eine kleine VM sein, mit Apache und ~30-50GB Speicherplatz 3. "Application" Server für Prosody/XMPP, und ggf. andere Das muss auch keine große VM sein, ~20GB reichen dicke... 4. Spielplatz - zum rumspielen halt Dachte an 50-100GB Plattenplatz und dann mal schauen was drauf läuft... Nun wie soll ich Anfangen? Ich könnte VM 2. - 4. ja von der SSD laufen lassen und dann die geplanten 3-4 * 4TB HDDs an die NAS VM durchreichen. Die Frage die ich mir nun stelle: Macht es Sinn die NAS FUnktionalität in eine VM auszulagern, und kann ich dann ein BTRFS Volume über 3 Platten (das ggf. erweiterbar sein soll) welches über irgendein RAID (das ist die nächste Frage...) Oder wäre es vllt. einfacher (aber unflexibler?) den Samba/NFS Server einfach auf dem Host system zu betreiben und irgendwas ONTOP (Fotoalbum / DLNA) einfach auszulagern? (oder auch gleich mit auf dem Host System zu betreiben?) Meine Vorstellung war halt, dass das Host System nur die Platform bereitstellt und ich dann die ganzen VMs mit LUKS(?) betreiben kann damit die Daten verschlüsselt sind. So kann ich bei einem Reboot des Hosts mich auf ihm per SSH einloggen udn dann die VMs starten. USV ist vorhanden, sollte also hoffentlich selten vorkommen. Raid? Welches nehmen? Gibt es eine Konfiguration die mir möglichst wenig Speicherplatz nimmt wenn die Plattengröße unterschiedlich ist und die mir möglichste Flexibilität erlaubt? In dem anderen Thread von letzter Woche (Beitrag "Hilfe: FreeNAS oder Debian") habe ich schon einige Erkenntnisse gewinnen können. Z.b. kannte ich ProxMox noch nicht und das sieht eigentlich so aus, als könnte ich damit wenigstens umsetzen das alles in einer eigenen VM läuft und ich mich um das Host System nicht zu sehr kümmern muss. Vor nem knappen Jahr dachte ich an OMV oder FreeNas, aber ich glaube das geht schon wieder zu viel in RIchtung Synology. Das mag zwar sehr einfach und schnell einzurichten sein, aber ich mag diese "Abhängigkeit" nicht. Vielleicht bin ich zu sehr durch Synology geschädigt (da war es jedenfalls für mich nicht so einfach irendwelche Programme die ich haben wollte, die es aber in deren "Appstore" nicht gab zu installiere) und bei FreeNas und OMV ist das besser als ich es mir vorstelle. Lange Rede kurzer Sinn: wie konfiguriere ich am besten die 3-4*4TB (oder 3*8, je nachdem wieviel Knete übrig bleibt ;)), sodass ich ein gewisses Maß an Redundanz habe falls mal eine Platte ausfällt und mir dabei auch die Flexibilität nicht nehme? Bei meinem Synology NAS ist das in 7 Jahren immerhin einmal passiert. Ging dann zum GLück recht einfach. Gleiche Platte nochmal gekauft (also gleiche Größe), eingebaut und Replizierung startete mehr oder weniger automatisch. Achso, das Synology NAS wollte ich dann nochmal neu aufsetzen und das kann als Backup Server für Fotos und Aufnahmen etc. dienen (das würde ich dann aber mit 2*2=4 TB als eigenständige Volumes machen, statt als RAID - mal schauen). Gar nicht so einfach - werde wohl noch einiges lesen müssen, aber vielleicht habt ihr ja den ein oder anderen Vorschlag oder kurze Best-Practice Beschreibung aus eurem Umfeld? danke! vgs
Sebastian J. schrieb: > Macht es Sinn die NAS FUnktionalität in eine VM auszulagern, und kann > ich dann ein BTRFS Volume über 3 Platten (das ggf. erweiterbar sein > soll) welches über irgendein RAID (das ist die nächste Frage...) > Oder wäre es vllt. einfacher (aber unflexibler?) den Samba/NFS Server > einfach auf dem Host system zu betreiben und irgendwas ONTOP (Fotoalbum > / DLNA) einfach auszulagern? (oder auch gleich mit auf dem Host System > zu betreiben?) Ich betreibe auch seit vielen Jahren einen VM Host mit mehreren VMs bei mir. Ich habe den Host immer schlank gehalten und damit gute Erfahrungen gemacht. Also ja, nimm die VM und reich die Festplatten per virtio durch. Allenfalls kannst Du überlegen, ob Du das BtrFs- oder was-auch-immer-Volume vom Host aus erstellst und dann dieses Volume durchreichst. Ich würde das aber komplett trennen, dann kannst Du immer schnell die VMs samt Platten auf einen anderen Host umziehen. > Meine Vorstellung war halt, dass das Host System nur die Platform > bereitstellt und ich dann die ganzen VMs mit LUKS(?) betreiben kann > damit die Daten verschlüsselt sind. So kann ich bei einem Reboot des > Hosts mich auf ihm per SSH einloggen udn dann die VMs starten. USV ist > vorhanden, sollte also hoffentlich selten vorkommen. Kannst Du machen, noch sicherer wäre es, das ganze System zu verschlüsseln, damit erst gar keiner mitbekommt, was darauf läuft. So habe ich das bei mir eingerichtet. > Raid? Welches nehmen? Gibt es eine Konfiguration die mir möglichst wenig > Speicherplatz nimmt wenn die Plattengröße unterschiedlich ist und die > mir möglichste Flexibilität erlaubt? RAID0 ;) > In dem anderen Thread von letzter Woche > (Beitrag "Hilfe: FreeNAS oder Debian") habe ich schon einige > Erkenntnisse gewinnen können. Z.b. kannte ich ProxMox noch nicht und das > sieht eigentlich so aus, als könnte ich damit wenigstens umsetzen das > alles in einer eigenen VM läuft und ich mich um das Host System nicht zu > sehr kümmern muss. Also unter Ubuntu musst Du mit KVM auch nicht viel machen. Die Einrichtung ist nicht schwer, nur ein paar Änderungen an der Default Config. Die Verwaltung dann über virtmanager auf dem Client. > Gar nicht so einfach - werde wohl noch einiges lesen müssen, aber > vielleicht habt ihr ja den ein oder anderen Vorschlag oder kurze > Best-Practice Beschreibung aus eurem Umfeld? Wie geschrieben: Bei Deinen Anforderungen ein Standard Ubuntu Linux, dazu KVM und virtmanager auf dem Client. Das System sowie die VMs auf eine SSD, die drei Festplatten über virtio an die NAS-VM durchreichen und dort ein RAID5 einrichten, dazu dann NFS, Samba, fertig ist die Geschichte. Mit ein bisschen Erfahrung hast Du das nach einem Tag laufen, mit ein bisschen mehr nach einem halben.
Ich nutze auf meinem Server mit Devuan Jessie libvirt+qemu für VMs und libvirt-lxc für Container. Container verbrauchen viel weniger Ressourcen als VMs, ich habe momentan eine pfSense VM und ~14 Devuan Container, auf denen Webserver, Mailserver, NFS Shares, etc. laufen, meine CPU Auslastung ist meistens bei etwa 0.1% oder niedriger, und von meinen 62G RAM hat mein Server im moment erst für 7GB verwendung gefunden, die Caches inklusive. Hier ist eine Anleitung für libvirt-lxc Container von mir: https://dev1galaxy.org/viewtopic.php?id=617 Was Verschlüsselung angeht kommt es beim optimalen Verfahren doch sehr auf das eigene threat model an. Will man sich gegen Polizeirads oder Diebstahl verteidigen, macht full disk encryption, und eventuell zusätzlich ein steganographic file system Layer Sinn. Will man die Daten vor Hackerangriffen schützen, und müssen diese vom Server nicht weiterverarbeitet werden, kann man stackable filesystem-level encryption verwenden, und die Daten nur auf dem Gerät wo sie gebraucht werden wieder entschlüsseln.
Vetmutlich braucht meine Dockstar für NFS und FTP inklusive USB-Platte weniger Energie als die brachliegenden 55 GB RAM. Aber jeder wie er will.
Erstmal Danke an dich und die anderen beiden für die Antworten! Dr. No schrieb: > Allenfalls kannst Du überlegen, ob Du das BtrFs- oder > was-auch-immer-Volume vom Host aus erstellst und dann dieses Volume > durchreichst. Ich würde das aber komplett trennen, dann kannst Du immer > schnell die VMs samt Platten auf einen anderen Host umziehen. Genau das war der Plan. Das Daten und System möglichst unabhängig voneinander sind. > Kannst Du machen, noch sicherer wäre es, das ganze System zu > verschlüsseln, damit erst gar keiner mitbekommt, was darauf läuft. So > habe ich das bei mir eingerichtet. Was machst du bei unerwarteten Powerdown? Musst du dann vor Ort das PW eintippen, oder gibts da noch einen Trick? > RAID0 ;) das wollte ich jetzt nicht hören ;) > Die Verwaltung dann über virtmanager auf dem Client. Danke für den Tipp! Das sieht ja von der Benutzung dann fast so aus als ließe ich VirtualBox lokal laufen :) > Wie geschrieben: Bei Deinen Anforderungen ein Standard Ubuntu Linux, > dazu KVM und virtmanager auf dem Client. Das System sowie die VMs auf > eine SSD, die drei Festplatten über virtio an die NAS-VM durchreichen > und dort ein RAID5 einrichten, dazu dann NFS, Samba, fertig ist die > Geschichte. Hört sich nach einem Plan an. Muss ich jetzt mal anfangen die Hardware zusammenzusuchen und zu bestellen. > Mit ein bisschen Erfahrung hast Du das nach einem Tag laufen, mit ein > bisschen mehr nach einem halben. Ich brauche sicher 2... Aber erstmal kommen noch zwei Reisen und dann im Dezember bzw. Ende Dezember habe ich die dann hoffentlich Zeit und hoffentlich bleibt noch ein Stündchen übrig um hier davon zu berichten - falls es wen interessiert ;) Daniel A. schrieb: > Ich nutze auf meinem Server mit Devuan Jessie libvirt+qemu für VMs und > libvirt-lxc für Container. Container verbrauchen viel weniger Ressourcen > als VMs, Das glaub ich dir gerne, aber da habe ich dann wirklich 0,0 Erfahrung und wenig Vorstellung davon wie das genauf funktioniert. Denke ich versuches mal mit VMs und kann dann ja mal ein paar Projekte als Container probieren. > Was Verschlüsselung angeht kommt es beim optimalen Verfahren doch sehr > auf das eigene threat model an. Will man sich gegen Polizeirads oder > Diebstahl verteidigen, macht full disk encryption, und eventuell > zusätzlich ein steganographic file system Layer Sinn. Bei mir ist es die permanente Angst, dass mal wer in den Keller einsteigt und einfach den Stecker zieht und die Kiste wegnimmt. Das sind nur ~2% wirklich persönliche Sachen drauf. Hab zwar einige hundert GB Urlaubsfotos, aber das könnte ich verschmerzen. Wichtiger sind mir persönliche Dokumente/REchnungen/Briefverkehr... Was ist denn der Vorteil von diesem "steganographic file system Layer"? wenn ich Full Disk Encryption mache, was ist der Mehrwert noch einen Layer drüber/drunter zu setzen? > vor Hackerangriffen schützen, und müssen diese vom Server nicht > weiterverarbeitet werden, kann man stackable filesystem-level encryption > verwenden, und die Daten nur auf dem Gerät wo sie gebraucht werden > wieder entschlüsseln. D.h. man ver/entschlüsselt das auf dem Client und auf dem SHare liegt sowas wie ein veschlüsselter Container? Hab ich bisher mit TrueCrypt Containern gemacht. War sehr einfach ind er Handhabung, sofern man das direkt vom Share übers Neztwerk mounten konnte. Ich sehe ich hab noch viel zu lesen. Und wie oben schon geschrieben erstmal viel Hardware zu kaufen. Danke euch aber schonmal für die Anregungen! vgs
Sebastian J. schrieb: > Was ist denn der Vorteil von diesem "steganographic file system Layer"? > wenn ich Full Disk Encryption mache, was ist der Mehrwert noch einen > Layer drüber/drunter zu setzen? Ein steganographic file system Layer ist sonnvoll, wenn man sich vor Polizei raids schützen will; Wenn die Behörden nicht wissen können, dass da noch ein Dateisystem versteckt ist, können sie auch kein Passwort zum entsperren verlangen.
Sebastian J. schrieb: >> Kannst Du machen, noch sicherer wäre es, das ganze System zu >> verschlüsseln, damit erst gar keiner mitbekommt, was darauf läuft. So >> habe ich das bei mir eingerichtet. > > Was machst du bei unerwarteten Powerdown? Musst du dann vor Ort das PW > eintippen, oder gibts da noch einen Trick? Trick nicht, aber dropbear ssh-server wird nach dem Neustart gestartet, und dann kann man sich per ssh einloggen und die Passphrase eingeben. Funktioniert aber nicht per Knopfdruck out-of-the-box, das muss man selber einrichten. > Daniel A. schrieb: > Ich nutze auf meinem Server mit Devuan Jessie libvirt+qemu für VMs > und > libvirt-lxc für Container. Container verbrauchen viel weniger Ressourcen > als VMs, ich habe momentan eine pfSense VM und ~14 Devuan Container, auf > denen Webserver, Mailserver, NFS Shares, etc. laufen, meine CPU > Auslastung ist meistens bei etwa 0.1% oder niedriger, und von meinen 62G > RAM hat mein Server im moment erst für 7GB verwendung gefunden, die > Caches inklusive. Mal abgesehen von der fragwürdigen massiven Überausstattung des Hosts sollte man noch etwas erwähnen: - Es gibt etliche Container-Lösungen für Linux, von denen die meisten noch schlanker als LXC sind, z.B. docker, rkt, systemd-nspawn - Container sind deutlich unsicherer als eine VM. Insbesondere Dienste, die nach aussen ins Internet geöffnet sind wie Mailserver und insbesondere Webserver würde ich niemals in einem Container auf dem Host laufen lassen. Über mehrere Container in einer VM könnte man diskutieren... Dann aber auch mit vernünftiger Absicherung über apparmor, selinux oder Ähnlichem
Dr. No schrieb: > - Es gibt etliche Container-Lösungen für Linux, von denen die meisten > noch schlanker als LXC sind, z.B. docker, rkt, systemd-nspawn docker, lxc, libvirt-lxc, etc. sind alles Linux Container (LXC), aber libvirt-lxc ist genausowenig lxc (die Software) wie docker lxc ist. Ich weiss, es ist verwirrend, dass libvirt-lxc lxc im Namen hat, und dass LXC eine Abkürzung eines Konzeptes und der name einer Software bestehend aus diversen Tools ist, aber libvirt-lxc hat wirklich nichts mit der lxc Software zutun, abgesehen davon, dass beide Linux Container verwalten.
Dr. No schrieb: > - Container sind deutlich unsicherer als eine VM. Insbesondere Dienste, > die nach aussen ins Internet geöffnet sind wie Mailserver und > insbesondere Webserver würde ich niemals in einem Container auf dem Host > laufen lassen. Bei einem Docker Container würde ich da zustimmen, nicht alle Layer von Docker images werden so oft aktualisiert wie nötig, und heufig werden z.B. ssh keys nicht neu generiert. Andere Container wie libvirt-lxc Containern sind zwar immernoch weniger sicher als eine VM, aber es kommt selten vor, dass eine Malware mehrere 0days beinhaltet, und um aus einem Container auszubrechen reicht ein userspace bug nicht aus, dort braucht man zusätzlich einen selteneren Kernel oder Treiber bug. Aber für den Notfall habe ich ja noch Backups auf einem separaten PC, der keine eingehenden Verbindungen annimmt und für nichts anderes verwendet wird, damit verliere ich bei Ransomware angriffen keine Daten.
:
Bearbeitet durch User
Daniel A. schrieb: > docker, lxc, libvirt-lxc, etc. sind alles Linux Container (LXC), aber > libvirt-lxc ist genausowenig lxc (die Software) wie docker lxc ist. Ich > weiss, es ist verwirrend, dass libvirt-lxc lxc im Namen hat, und dass > LXC eine Abkürzung eines Konzeptes und der name einer Software > bestehend aus diversen Tools ist, aber libvirt-lxc hat wirklich nichts > mit der lxc Software zutun, abgesehen davon, dass beide Linux Container > verwalten. Nein, das ist falsch, leider bist Du verwirrt worden... libvirt ist eine Software (Daemon libvirt-bin, API sowie Kommandozeilenwerkzeug virsh) zur Verwaltung und Steuerung der diversen Container- und Virtualisierungslösungen, ob dies nun ESX, QEMU/KVM, LXC, OpenVZ oder sonstwas ist. Du nutzt lxc-Container und verwaltest sie mit libvirt. Libvirt-lxc hat also sehr wohl etwas mit lxc zu tun, es ist nämlich die Schnittstelle zwischen libvirt und lxc.
Daniel A. schrieb: > Bei einem Docker Container würde ich da zustimmen, nicht alle Layer von > Docker images werden so oft aktualisiert wie nötig, und heufig werden > z.B. ssh keys nicht neu generiert. Andere Container wie libvirt-lxc > Containern sind zwar immernoch weniger sicher als eine VM, aber es kommt > selten vor, dass eine Malware mehrere 0days beinhaltet, und um aus einem > Container auszubrechen reicht ein userspace bug nicht aus, dort braucht > man zusätzlich einen selteneren Kernel oder Treiber bug. Aber für den > Notfall habe ich ja noch Backups auf einem separaten PC, der keine > eingehenden Verbindungen annimmt und für nichts anderes verwendet wird, > damit verliere ich bei Ransomware angriffen keine Daten. Nein, das entscheidende Merkmal ist, dass Container auf dem gleichen Kernel wie das Hostsystem laufen und nur durch Namespaces, CGroups, etc. abgegrenzt sind. Virtuelle Maschinen laufen aber komplett separiert. Und aus eben diesem Grund ist die Sicherheit prinzipbedingt deutlich geringer und muss dann eben durch weitere Massnahmen flankiert werden.
Soweit ich weiß, ist RAID5 bei BTRFS immer noch nicht stabil. Das macht aber auch mit anderen Technologien immer wieder Probleme. Lieber eine HDD mehr kaufen, und mit RAID1(0) sorgenfrei leben.
Dr. No schrieb: > Du nutzt lxc-Container und verwaltest sie mit libvirt. Libvirt-lxc hat > also sehr wohl etwas mit lxc zu tun, es ist nämlich die Schnittstelle > zwischen libvirt und lxc. Das mag ja bei z.B. qemu und einigen anderen Dingen der Fall sein, aber es trifft nicht auf libvirt-lxc zu. Bei libvirt+qemu muss man qemu installieren, nicht so bei libvirt-lxc. Ich habe die lxc und lxd Packete nicht installiert, und es gibt auch keine Pakete für lxc libraries von denen das lxc packet abhängt, somit kann libvirt auch keine derartige library verwenden. Auch lxc-ls nach der lxc installation zeigt die libvirt-lxc container nicht an. Hier ein Auszug aus meinem Terminal, auf die Erklärung wie dass mit deiner Aussage zusammenpasst bin ich sehr gespannt:
1 | root@mouse:~# virsh -c lxc:/// list --title |
2 | Id Name State Title |
3 | ---------------------------------------------------------------------------------- |
4 | 3432 beaver running Build Server |
5 | 4279 butterfly running Tor Gateway + DNS |
6 | 5787 snake running APT-Mirror & TOR Webserver |
7 | 7321 pxeenv running LXC Container for administrating PXE Environment |
8 | 8491 dog running tftp Server vor PXE Boot |
9 | 10648 duck running DMZ DNS Server |
10 | 12871 rat running SSH Backdoor |
11 | 12923 kiwi running |
12 | 13785 zebra running NFS, WebDav & SMB Server |
13 | 14983 kangaroo running Public DNS |
14 | 15772 fox running Logging server |
15 | 17167 frog running Webserver |
16 | 18897 pelican running Mail Server |
17 | 19874 leopard running Print Server |
18 | |
19 | root@mouse:~# apt-get install lxc |
20 | Reading package lists... Done |
21 | Building dependency tree |
22 | Reading state information... Done |
23 | Suggested packages: |
24 | lua5.2 |
25 | The following NEW packages will be installed: |
26 | lxc |
27 | 0 upgraded, 1 newly installed, 0 to remove and 38 not upgraded. |
28 | Need to get 0 B/625 kB of archives. |
29 | After this operation, 2,669 kB of additional disk space will be used. |
30 | Selecting previously unselected package lxc. |
31 | (Reading database ... 951362 files and directories currently installed.) |
32 | Preparing to unpack .../lxc_1.0.6-6+deb8u6_amd64.deb ... |
33 | Unpacking lxc (1:1.0.6-6+deb8u6) ... |
34 | Processing triggers for man-db (2.7.0.2-5) ... |
35 | Setting up lxc (1:1.0.6-6+deb8u6) ... |
36 | Processing triggers for libc-bin (2.19-18+deb8u10) ... |
37 | root@mouse:~# lxc-ls |
38 | root@mouse:~# apt-get remove lxc |
39 | Reading package lists... Done |
40 | Building dependency tree |
41 | Reading state information... Done |
42 | The following packages will be REMOVED: |
43 | lxc |
44 | 0 upgraded, 0 newly installed, 1 to remove and 38 not upgraded. |
45 | After this operation, 2,669 kB disk space will be freed. |
46 | Do you want to continue? [Y/n] |
47 | (Reading database ... 951761 files and directories currently installed.) |
48 | Removing lxc (1:1.0.6-6+deb8u6) ... |
49 | Processing triggers for man-db (2.7.0.2-5) ... |
50 | Processing triggers for libc-bin (2.19-18+deb8u10) ... |
51 | root@mouse:~# apt-cache depends lxc |
52 | lxc |
53 | Depends: init-system-helpers |
54 | Depends: libapparmor1 |
55 | Depends: libc6 |
56 | Depends: libcap2 |
57 | Depends: libseccomp2 |
58 | Depends: libselinux1 |
59 | Depends: python3 |
60 | Depends: python3 |
61 | PreDepends: multiarch-support |
62 | Suggests: lua5.2 |
63 | Recommends: debootstrap |
64 | Recommends: openssl |
65 | Recommends: rsync |
66 | Conflicts: <lxc-dev> |
67 | Replaces: <lxc-dev> |
Dr. No schrieb: > Nein, das entscheidende Merkmal ist, dass Container auf dem gleichen > Kernel wie das Hostsystem laufen und nur durch Namespaces, CGroups, etc. > abgegrenzt sind. Virtuelle Maschinen laufen aber komplett separiert. Und > aus eben diesem Grund ist die Sicherheit prinzipbedingt deutlich > geringer und muss dann eben durch weitere Massnahmen flankiert werden. Schon klar, dennoch gab es auch schon bei VMs Ausbrüche. Aus einem Namespace kommt man eventuell etwas leichter, aber auch nicht ohne einen 0day heraus, ein häcker müsste also ersteinmal hineinkommen und einen 0day für den Kernel haben um aus dem Namespace herauszukommen. Ich halte das einfach für sehr unwahrscheinlich.
Jan H. schrieb: > Soweit ich weiß, ist RAID5 bei BTRFS immer noch nicht stabil. Das ist korrekt, Probleme kann das bei einem Stromausfall machen. Erst kürzlich wurde ein Patch dafür eingereicht. https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg66472.html Daher sollte man das noch nicht verwenden. Verwenden kann man die Kernel-Raid-Funktionen, verwaltet werden die mit mdadm. Auf das RAID dann ein Dateisystem nach Belieben.
Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren NAS wollen. Es hilft nicht gegen Diebstahl, Überspannung, Viren, eigene Dummheit, sondern ausschließlich gegen Festplattendefekt. Mit anderen Worten: Ein Backup braucht man sowieso. Wenn ich das habe, kann ich mir aber auch gleich das RAID sparen und in mehr Speicherkapazität (Oder mehr offline-Backups) investieren - da werde ich wohl mehr von haben auf Dauer. RAID ist ja eigentlich nur sinnvoll, wenn eben 100% Verfügbarkeit wichtig sind. Prinzipiell kann man aber bei einem Festplattencrash im NAS halt auch mal einen Tag verzichten, dafür den Rest der Zeit mehr Geld im Portemonaie oder mehr Kapazität im NAS genießen - JustMy2Cents.
Daniel A. schrieb: > Hier ein Auszug aus meinem Terminal, auf > die Erklärung wie dass mit deiner Aussage zusammenpasst bin ich sehr > gespannt: Ganz einfach: Libivrt hat einen eigenen Treiber für LXC, dafür braucht es natürlich die Tools aus dem LXC-Paket nicht. Steht aber alles in der Doku: "The libvirt LXC driver has no dependency on the LXC userspace tools" Ich empfehle Dir dringend, Dich mit den eingesetzten Techniken wenigstens ein bisschen auseinanderzusetzen, bevor Du solch sachlich falsche Aussagen machst. Andere könnten das glauben... Zum Lesen z.B.: https://libvirt.org/drvlxc.html
Dr. No schrieb: > Ganz einfach: Libivrt hat einen eigenen Treiber für LXC, dafür braucht > es natürlich die Tools aus dem LXC-Paket nicht. Steht aber alles in der > Doku: > "The libvirt LXC driver has no dependency on the LXC userspace tools" > > Ich empfehle Dir dringend, Dich mit den eingesetzten Techniken > wenigstens ein bisschen auseinanderzusetzen, bevor Du solch sachlich > falsche Aussagen machst. Andere könnten das glauben... Aber das bestätigt doch ausschliesslich meine aussagen, aber nicht deine! Linux Container (LXC), also das Konzept, sind Container auf Linux, und das sind eigentlich nur Namespaces und CGroups. lxc (Die Software), oder hier als LXC Tools bezeichnet, sind Tools um Linux Container zu erstellen. Aber docker und libvirt-lxc sind ebenfalls tools um Linux Container zu erstellen. Dein oberes Zitat explizit bestätigt, dass libvirts LXC Treiber nichts mit den LXC Tools zutun hat, was von Anfang an meine Aussage war. Meine Aussagen von oben sind mit dem Zitat absolut konsistent: Daniel A. schrieb: > docker, lxc, libvirt-lxc, etc. sind alles Linux Container (LXC), aber > libvirt-lxc ist genausowenig lxc (die Software) wie docker lxc ist. Ich > weiss, es ist verwirrend, dass libvirt-lxc lxc im Namen hat, und dass > LXC eine Abkürzung eines Konzeptes und der name einer Software > bestehend aus diversen Tools ist, aber libvirt-lxc hat wirklich nichts > mit der lxc Software zutun, abgesehen davon, dass beide Linux Container > verwalten. Deine aussage war jedoch: Dr. No schrieb: > Du nutzt lxc-Container und verwaltest sie mit libvirt. Libvirt-lxc hat > also sehr wohl etwas mit lxc zu tun, es ist nämlich die Schnittstelle > zwischen libvirt und lxc. Gratulation, du hast dich selbst wiederlegt.
jz23 schrieb: > Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren > NAS wollen. Es hilft nicht gegen Diebstahl, Überspannung, Viren, eigene > Dummheit, sondern ausschließlich gegen Festplattendefekt. Persönliche Statistik in knapp 7 Jahren NAS Nutzung: Diebstähle: 0 Festplattenausfälle: 1 Klar braucht man noch ein Backup. Auch wegen Feuer, Wasser und sonstigen unvorhergesehenen Naturkatastrophen wo mir das RAID nicht hilft... > JustMy2Cents. So isses. Aber trotzdem danke für deine Meinung zum Thema! Mir geht es besser mit RAID. Vielleicht ändere ich meine Meinung noch... Zusätzliches Backup soll ja das Alte NAS werden, sobald das einmal zurück gesetzt wurde.al schauen in welchem Raum ich das dann unterbringe, damit es nicht gleich daneben steht (von wegen Feuer und Diebstahl - hilft nicht bei Feuer oder Dieben mit viel Zeit ;))
jz23 schrieb: > Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren > NAS wollen. Es hilft nicht gegen Diebstahl, Überspannung, Viren, eigene > Dummheit, sondern ausschließlich gegen Festplattendefekt. Mit anderen > Worten: Ein Backup braucht man sowieso. Wenn ich das habe, kann ich mir > aber auch gleich das RAID sparen ... Das ist gar kein Argument. Genauso könnte man gegen Krankenwagen argumentieren: "Ich verstehe nicht, warum alle Leute wollen, daß Krankenhäuser Krankenwagen haben. Die kommen ja nur dahin, wo es fahrbare Wege gibt. Wenn ich im Gebirge verunglücke oder im Meer am Ertrinken bin, hilft mir ein Krankenwagen gar nicht. Da brauche ich einen Lebensretter. Und wenn ich den habe, dann ist der Krankenwagen unnütz ..." Trotzdem retten Krankenwagen nachweislich Leben. Bei einem RAID ist es ganz ähnlich. Das RAID erlaubt mir überhaupt erst, viel Speicher am Stück zu haben, ohne daß mir ein Plattenausfall gleich Daten vernichtet. Das Backup macht das RAID nicht unnütz, es ist eher anders herum: ohne RAID könnte ich gar nicht die Daten speichern, die ich nachher (vielleicht mal) in ein Backup tun will. Dazu kommt noch: nicht alle Daten, die man auf ein RAID tut, sind auch backupwürdig. Ich habe hier z.B. ein größeres Multimedia-Archiv. Musik, Filme, Urlaubsfotos, Bücher, gescannte Zeitschriften etc. Nur ein Teil davon ist backupwürdig. Musik und Filme sind im Zweifel wiederbeschaffbar, Urlaubsbilder eher nicht. Entsprechend landet nur ein Teil davon auch im Backup. Konkrete Zahlen: mein großes RAID hat 22TB (6x 4TB im RAID-6), Davon sind 10TB belegt. Im Backup sind 1.8TB, was 4 Generationen aus dem Datenbereich und um die 100 Generationen von /home, /var (Mail!) und der Betriebssystem-Installation der diversen Rechner ist. Das Backup verwendet Hardlinks für alte Versionen. Eine Datei, die sich nicht ändert, belegt für 100 Generationen also nur unwesentlich mehr Platz als für eine. Und schließlich noch ein letzter Punkt: worauf willst du denn bitte dein Backup machen? Bei wirklich großen Datenmengen? Doch am Ende auch wieder auf einer Festplatte. Bzw. besser auf einem RAID, sobald es größer wird als eine Einzelplatte. Bandlaufwerke mit adäquater Kapazität und Geschwindigkeit sind für den Privatanwender unerschwinglich. Wenn du deine offline-Backups bei Amazon oder sonstwo machst, was glaubst du, wo deine Daten landen? Auf einem RAID natürlich.
> Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren > NAS wollen. Ich auch nicht. Ungespiegelte Platten gehen nicht kaputt. I.S.S.O. Lieber mal hd1 auf hd2 spiegeln und dann hd2 weitermachen lassen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.