Wie viel RAM braucht ein NAS? Der Ratgeber nach System 2026

Aktualisiert: 2026-07-23· Zuletzt geprüft Juli 2026

Kaum eine NAS-Frage bekommt eine so aufgeblähte Antwort wie diese. Frag ein Forum, wie viel RAM deine Kiste braucht, und einer zitiert eine Regel, die mit der Plattengröße wächst, der Nächste besteht darauf, dass 64 GB das vernünftige Minimum seien, und ein Dritter erzählt dir, sein Vier-Platten-Synology laufe seit einem Jahrzehnt ohne Zucken auf 2 GB. Alle drei beschreiben verschiedene Maschinen mit verschiedenen Aufgaben, und genau deshalb passt eine einzelne Zahl nie. Wie viel Speicher ein NAS braucht, bestimmt fast ausschließlich die Software, die darauf läuft, und die Extras, die du obendrauf packst, weshalb die nützliche Antwort nach System sortiert ist: mit konkreten Werten und einem Hinweis, wann jeder davon steigen sollte. Wer das größere Bild sucht, wie das Betriebssystem jede andere Hardware-Entscheidung treibt, findet es im NAS-Hardware-Ratgeber; hier bleiben wir eng und beantworten die RAM-Frage direkt.

Die kurze Antwort, dann die Tabelle

Der Mechanismus, der fast alles darunter erklärt, ist simpel: Ein NAS nutzt freien Speicher als Cache für zuletzt berührte Dateien, fühlt sich deshalb bei warmen Daten schnell an und gibt diesen Speicher sofort zurück, sobald eine Anwendung ihn braucht. Deshalb ist "freies RAM ist verschwendetes RAM" ein fairer Spruch, und deshalb ist eine Kiste, die fast ihren gesamten Speicher "belegt", eben keine Kiste, die zu wenig davon hat. Die reine Kapazität bewegt den Wert kaum, denn eine 40-TB-Bibliothek und eine mit 4 TB zu cachen kostet ungefähr denselben Leerlauf-Fußabdruck; was ihn bewegt, sind laufende Programme, ob das nun VMs, Container oder ein ZFS-Feature ist, das Speicher gegen einen konkreten Vorteil eintauscht. Die Tabelle unten ist die kurze Antwort für die fünf Systeme, die tatsächlich installiert werden.

Lies die Tabelle als Untergrenze und komfortables Ziel, nicht als Decke: Nichts geht kaputt, wenn du mehr verbaust, und die Spalte "Mehr, wenn" ist der ehrliche Auslöser fürs Ausgeben. Die Quintessenz: Für ein erstes NAS, dessen Job Dateien, Backups und vielleicht ein paar Apps sind, sind 8 GB über fast jedes System hinweg ein sinnvoller Landeplatz, und die Abschnitte darunter erklären, warum jedes System dort liegt, wo es liegt.

Appliance-NAS: Synology DSM und QNAP

Eine versiegelte Appliance ist darauf getrimmt, sich auf bescheidenem Speicher flott anzufühlen, und deshalb reichen die serienmäßigen 2 bis 4 GB in einem Einsteiger-Synology oder -QNAP für die Kernaufgabe wirklich aus: Dateien teilen und Backups laufen lassen. ASUSTOR, das dieselbe Geräteklasse verkauft, sagt in seinem eigenen Leitfaden unverblümt, dass 2 bis 4 GB für einfache Dateiablage und -freigabe reichlich sind, während 8 GB oder mehr sich lohnen, sobald Virtualisierung, mehrere Apps oder schwerere Dienste dazukommen. In dem Moment, in dem deine Appliance kein Dateiserver mehr ist, sondern ein kleiner Anwendungsserver, wird dieser Werkswert knapp.

Was eine Appliance tatsächlich nach mehr RAM verlangen lässt, ist berechenbar: ein Stapel Docker-Container, eine Synology Surveillance Station, die mehrere Kameras aufnimmt, eine Fotos-Bibliothek, die ihren Gesichts- und Objekt-Index aufbaut, oder eine leichte VM. Die Falle, auf die du achten musst: Viele Einsteiger-Modelle mit zwei und vier Bays verlöten ihren Speicher fest, das RAM vom ersten Tag ist also das RAM, das du behältst. Wenn du schon weißt, dass du Container, Kamera-Aufnahmen oder Foto-Indizierung willst, ist der konkrete Zug, eine Modellstufe zu wählen, die mit 8 GB kommt oder einen SODIMM-Slot bietet, statt zwanzig Euro an einer Kiste zu sparen, die du nicht erweitern kannst. Welche Stufe das ist, hängt an derselben Plattform-Entscheidung, die unser NAS-Kaufratgeber durchgeht.

OpenMediaVault und schlichtes Debian: die RAM-sparsame Basis

OpenMediaVault sitzt am sparsamen Ende der Skala, weil es eine dünne Verwaltungsschicht über Debian Linux ist, und Debian gibt sich mit sehr wenig zufrieden. Die eigenen Hardware-Voraussetzungen des Projekts nennen 1 GiB RAM als Minimum, weshalb OpenMediaVault die klassische Wahl für einen Raspberry Pi oder einen recycelten Mini-PC mit ein paar Platten ist. In der Praxis geben dir 2 bis 4 GB komfortablen Spielraum für das Web-Interface, SMB-Freigaben und eine Handvoll Plugins, ohne dass du je über Speicher nachdenkst.

Der Wert fängt erst dann an zu zählen, wenn du OpenMediaVault mit den Docker- und Portainer-Plugins erweiterst und Container fährst, denn dann werden die Container zum Budget, nicht das Basissystem. Weil eine schlichte Debian- oder OpenMediaVault-Kiste ext4 oder Btrfs statt ZFS nutzt, gibt es keinen ARC-Cache, der still Speicher beansprucht, was du also Containern zuteilst, ist ungefähr das, was die Maschine verbraucht. Die Quintessenz: Für einen einfachen Dateiserver auf OpenMediaVault sind 4 GB großzügig, und mehr planst du erst, wenn du weißt, dass die Container-Liste wächst. Wenn du das gegen die Alternativen abwägst, ordnet unser Vergleich Unraid vs. TrueNAS vs. OpenMediaVault ein, wo jedes System hinpasst.

Unraid: das Array ist billig, die Extras sind es nicht

Unraid ist das klarste Beispiel dafür, warum reine Kapazität die falsche Bezugsgröße für RAM ist. Sein Array liest und schreibt jeweils eine Platte statt über alle zu stripen, das Array selbst ist also anspruchslos beim Speicher, egal wie viele Terabyte es hält, und schon 4 GB betreiben die reine Storage-Seite. Der Grund, warum Leute 16, 32 oder 64 GB in eine Unraid-Kiste stecken, hat nichts mit dem Array zu tun und alles mit dem, was sie obendrauf schichten.

Genau dort liegt das echte Budget: die Docker-Container, die die meisten Unraid-Nutzer betreiben, eine oder mehrere virtuelle Maschinen und der Speicher, den ein aktiver NVMe-Cache-Pool gern um sich hat. Ein Media-Server mit einem Dutzend Container plus einer Windows-VM ist eine wirklich andere Maschine als ein nackter Dateiserver, und 8 GB sind eine komfortable Basis fürs Array plus ein leichtes Container-Set, während der Sprung zu mehr RAM von deiner konkreten App- und VM-Liste getrieben wird. Da Self-Hosting der ganze Zweck der meisten Unraid-Builds ist, ist unser Leitfaden zum Self-Hosting auf dem NAS der bessere Ort, um diesen Container-Hunger zu bemessen, und der oben verlinkte OS-Vergleich zeigt, wo Unraids Ein-Platten-Modell gewinnt und verliert. Die Quintessenz: Bemiss Unraid-RAM, indem du Container und VMs zusammenzählst und das Array als nahezu kostenlos behandelst.

TrueNAS und ZFS: der 1-GB-pro-TB-Mythos

Das ist das System, um das die Folklore gebaut wurde, es verdient also die klarste Richtigstellung. ZFS behandelt freien Speicher als Lesecache namens Adaptive Replacement Cache, kurz ARC, der zuletzt genutzte gegen häufig genutzte Daten ausbalanciert, damit sich ein warmer Pool selbst auf drehenden Platten schnell anfühlt. Weil dieser Cache sich ausdehnt, um das RAM zu füllen, das du ihm gibst, und in dem Augenblick schrumpft, in dem eine Anwendung Speicher braucht, kauft mehr RAM vor allem schnellere Reads statt eine harte Pflicht zu erfüllen, das genaue Gegenteil davon, wie die Regel "1 GB pro TB" es rahmt.

Die ehrlichen Zahlen sind viel sanfter als die Regel. Der TrueNAS-Hardware-Leitfaden behandelt 8 GB als Arbeitsbasis und lenkt die meisten Builds Richtung 16 GB, was bedeutet, dass ein 40-TB-Home-Media-Pool bestens auf 16 oder 32 GB läuft statt auf den 40 GB, die die Faustregel verlangen würde. Das Einzige, was wirklich mit der Kapazität skaliert, ist die Deduplizierung, die derselbe Leitfaden auf rund 5 GB RAM pro TB deduplizierter Daten beziffert, und Dedup ist ein Feature, das du bewusst einschaltest, kein Standard. Es lohnt zu wissen, dass die Faustregel nicht ganz verschwunden ist: Selbst die Proxmox-Systemanforderungen nennen weiterhin rund 1 GB Speicher pro TB, wenn der Host ZFS fährt, als konservative Planungsgröße, nicht als Wand. Wo zusätzliches RAM bei ZFS seinen Platz wirklich verdient, ist enger, als man denkt: Dedup wie oben, metadatenlastige Pools mit Millionen kleiner Dateien und Mehrbenutzer- oder Virtualisierungs-Workloads, bei denen ein größerer Cache die Trefferquote hebt. Für die volle ARC-Geschichte plus ECC, HBAs und Cache-Geräte geht unser Deep Dive zu den ZFS-Hardware-Anforderungen eine Ebene tiefer; die Quintessenz hier: Starte einen Home-ZFS-Pool bei 16 GB, geh auf 32 GB bei vielen Nutzern oder VMs, und jage einer Pro-TB-Zahl nur nach, wenn du Dedup bewusst aktivierst.

Proxmox und Virtualisierung: die VMs setzen das Budget

Proxmox dreht die ganze Rahmung um, denn ein Virtualisierungs-Host wird durch seine Gäste definiert, nicht durch seinen Speicher. Der Hypervisor selbst ist leicht: Die Proxmox-VE-Anforderungen verlangen rund 2 GB fürs Betriebssystem und seine Dienste, und danach legt jede virtuelle Maschine und jeder Container seine feste Zuteilung obendrauf. Eine Windows-VM, der du 8 GB gibst, nimmt wirklich 8 GB aus dem Pool, die Speicher-Rechnung ist also additiv auf eine Weise, wie sie es auf einem schlichten Dateiserver nie ist.

Das macht die Dimensionierung zu einer Einkaufsliste statt zu einer Regel: Zähl zusammen, was jede geplante VM und jeder Container braucht, addier die paar Gigabyte des Hosts und lass Spielraum für den ZFS-ARC, falls der Host ZFS-Storage nutzt. Ein Homelab, das ein paar VMs plus einen Container-Stack fährt, landet realistisch bei 16 bis 32 GB, und schwerere Labs klettern von dort weiter. Weil der Workload es treibt, gilt dieselbe Self-Hosting-Planung: erst die Dienste festlegen, dann das RAM kaufen, das sie zusammen ergeben. Die Quintessenz: Bemiss Proxmox-RAM für die Gäste, behandle den Host als Rundungsfehler und lass immer Platz, um eine weitere Maschine hochzufahren.

Was wirklich RAM frisst, und was nicht

Sobald du aufhörst, Speicher gegen die Plattengröße zu bemessen, hilft es zu wissen, welche Workloads ihn wirklich verbrauchen und welche still unschuldig sind, denn genau in diesem Unterschied passiert das meiste Zuviel-Ausgeben. Die Liste unten sortiert die üblichen Verdächtigen, und die letzten beiden Einträge sind die, die man am häufigsten verkehrt herum hat.

• Virtuelle Maschinen sind der größte Einzelverbraucher, weil du jeder einen festen RAM-Block zuteilst, der reserviert bleibt, solange die VM läuft.
• Docker-Container sind einzeln bescheiden, summieren sich aber über einen Stack, und die datenbankgestützten wie Immich oder Nextcloud sind schwerer als ein simpler Hilfscontainer.
• ZFS-Deduplizierung ist der wahre Ursprung der Pro-TB-Regel, mit rund 5 GB RAM pro TB deduplizierter Daten, weshalb sie ein Opt-in-Feature ist und kein Standard.
• Caching nutzt jeden freien Speicher als Lesecache, hohe "belegt"-Werte sind also normal und gesund; das System gibt diesen Speicher in dem Moment zurück, in dem ein Programm ihn braucht.
• Video-Transcoding ist der berühmte Fehlalarm: Es ist CPU- oder GPU-Arbeit, kein RAM-Problem. Jellyfins eigene Doku beschreibt, wie das On-the-fly-Transcoding auf eine GPU ausgelagert wird, damit es effizient läuft, ohne die CPU zu belasten, und weder Plex noch Jellyfin machen den Speicher zum Flaschenhals.

Diesen letzten Punkt solltest du festhalten, wenn du eine Media-Kiste planst, denn der Reflex, "für Plex" mehr RAM zu kaufen, geht daneben. Was ein Media-Server wirklich will, ist eine CPU oder GPU mit Hardware-Transcoding, was unser Leitfaden zum Plex-Media-Server-Speicher neben der Storage-Seite behandelt. Für Bastler: Bevor du Geld für Speicher ausgibst, miss die Maschine unter realistischer Last mit free -h oder htop, und prüf bei ZFS die ARC-Trefferquote mit arcstat; eine Trefferquote, die unter Last hoch bleibt, heißt, der Cache ist komfortabel und mehr RAM brächte wenig, während eine Trefferquote, die unter Last einbricht, das echte Signal zum Nachrüsten ist. Dieser gemessene Ansatz schlägt jedes Mal das Bemessen über die Pool-Kapazität. Die Quintessenz: Finanziere VMs, Container und Dedup großzügig und hör auf, dir um Transcoding und reine Kapazität Sorgen zu machen.

Ein kurzes Wort zu ECC

Eine Klarstellung verhindert eine häufige Verwechslung: Wie viel RAM du brauchst und ob dieses RAM ECC sein soll, sind zwei getrennte Fragen. ECC (Error-Correcting Code) geht es um Datenintegrität, es korrigiert still den gelegentlichen Single-Bit-Flip, bevor er deine Platten erreicht, nicht um Kapazität oder Tempo, ECC ändert also nichts an den Zahlen der Tabelle oben. OpenZFS selbst nennt ECC dringend empfohlen statt Pflicht, und die gruseligen ZFS-spezifischen Horrorgeschichten sind ein Mythos. Die ehrliche Kurzfassung: ECC lohnt sich bei einem Build, dessen ganzer Daseinszweck unersetzliche Daten sind, und ist bei einer lockeren Media-Kiste verzichtbar, aber den ganzen Fall führen wir, samt der Frage, welche Plattformen es unterstützen, in ECC-RAM fürs NAS und ZFS aus. Die Quintessenz: Entscheide zuerst die Menge aus deinem Workload, dann getrennt, ob die Daten ECC rechtfertigen.

Empfehlung: was du tatsächlich kaufst

Für einen schlichten Dateiserver, ein Backup-Ziel oder eine Time-Machine-Kiste sind 4 bis 8 GB die ganze Geschichte, und auf einer Appliance ist der Werksspeicher meist in Ordnung. Für einen Media-Server mit ein paar Containern (Plex oder Jellyfin plus die üblichen Helfer-Apps) sind 8 GB der komfortable Landeplatz, und das Geld, das du in mehr RAM stecken würdest, ist in einer CPU mit Hardware-Transcoding besser aufgehoben. Für einen TrueNAS- oder ZFS-Home-Pool startest du bei 16 GB und gehst nur dann auf 32 GB, wenn du viele gleichzeitige Nutzer oder VMs dazunimmst; ignorier die 1-GB-pro-TB-Regel, außer du aktivierst Deduplizierung bewusst, wo du stattdessen rund 5 GB pro TB einplanst. Für ein Homelab mit virtuellen Maschinen auf Unraid oder Proxmox bemisst du das RAM, indem du Gäste und Container zusammenzählst, was realistisch 32 GB oder mehr bedeutet. Über alle hinweg schlägt eine Gewohnheit jede Regel: Wenn das Board es erlaubt, kauf eine Stufe höher und lass einen Slot frei, sonst starte vernünftig und lass die reale Auslastung, nicht einen Forenthread, dir sagen, wann du nachrüstest. Wenn der Speicher steht, prüf die Platten und das Pool-Layout dahinter gegen echte Modelle in unserer NAS-Festplatten-Datenbank und dimensioniere die Kapazität selbst im RAID-Rechner.

Verwandte Artikel

NAS-Hardware-Ratgeber 2026: Worauf es je nach OS und Dateisystem ankommt

ZFS-Hardware-Anforderungen 2026: RAM, ECC, HBA und SLOG

ECC-RAM fürs NAS und ZFS: Pflicht oder Mythos?

Unraid vs. TrueNAS vs. OpenMediaVault: der komplette NAS-OS-Vergleich

Self-Hosting auf dem NAS: Cloud-Abos durch eigene Dienste ersetzen