TrueNAS 27 RC.1 är tillgänglig för utvärdering

TrueNAS publicerade 27.0.0-RC.1 den 6 oktober 2026. Det är en faktiskt tillgänglig release candidate, inte bara en presentation av framtida funktioner. Den officiella annonseringen beskriver versionen som Early Release för testning och återkoppling, inte för kritiska arbetslaster. För den som driver lagring åt virtuella maskiner eller backupjobb är den skillnaden viktigare än versionsnumret.

Numret har också bytt betydelse. I namnändringen som presenterades den 5 oktober förklarar TrueNAS att den tidigare 26-betan blir 27 från RC.1. Namnet avspeglar året då versionen väntas användas mest, inte en helt ny utvecklingsgren. Planen för 27.0 ligger fortfarande i början av december 2026. Det är en plan, inte ett löfte om att alla nya funktioner då är produktionsgodkända.

Nyhetsvärdet för LabOps IT ligger framför allt i lagringsarkitekturen: ett nytt inbyggt S3-gränssnitt, TrueNAS Object Interface. Det kan bli relevant för lokala applikationer och backupmiljöer, men tillgänglighet, kompatibilitet och licensiering behöver hållas isär.

Inbyggt S3 på ZFS förändrar integrationspunkten

Enligt TrueNAS genomgång av RC.1-funktionerna integreras S3 direkt i lagringsplattformen i stället för att kräva en separat tredjepartsapplikation i container. Varje bucket motsvarar ett ZFS-dataset. Därmed knyts objektlagring till plattformens lagringshantering, exempelvis snapshots, kvoter och replikering.

Det betyder inte att all drift blir enklare automatiskt. LabOps IT:s analys är att färre separata komponenter kan minska antalet integrationspunkter, men också samla fler beroenden i samma uppgraderingsdomän. Ett fel i lagringsplattformen kan beröra både fil- och objektkonsumenter. Införandet bör därför bedömas som en arkitekturförändring, inte som en extra kryssruta.

För ett homelab kan det vara intressant att testa en lokal applikation mot en egen S3-endpoint utan att samtidigt införa en separat objektlagringsplattform. För en organisation bör pilotens första fråga vara vilken konkret arbetslast som förbättras. En befintlig fungerande lösning behöver inte flyttas bara för att ett mer integrerat alternativ finns.

Gränssnittet är uttryckligen Early Access. Leverantören anger full produktionsstatus för funktionen under 2027. Den tidplanen ska inte blandas ihop med den planerade 27.0-releasen i december.

Samma lagring innebär inte fri skrivning via alla protokoll

Här är detaljdokumentationen mer avgränsad än den övergripande produktbeskrivningen. Konfigurationsguiden för S3, senast ändrad den 6 oktober, beskriver SMB- och NFS-delning av bucketinnehåll som skrivskyddad. Delningen använder multiprotokollmodellen och riktas mot datasetets s3data-katalog. Endast S3-tjänsten får skriva till bucketdatasetet.

Det är därför missvisande att tolka nyheten som att samma filer kan ändras fritt via både SMB, NFS och S3. För en applikation som vill läsa resultat via filprotokoll kan modellen vara användbar. För ett befintligt flöde där användare redigerar samma innehåll via SMB behöver man först kontrollera om arbetsmönstret alls passar.

Guiden anger dessutom att Object Lock inte är tillgängligt med multiprotokollmodellen. Diagrammet nedan visar därför två olika val: S3 med separat läsning via filprotokoll, eller ett S3-backupmål med Object Lock. Det visar inte att båda funktionerna kan kombineras på samma bucket.

Cyan visar S3-skrivning och violett SMB/NFS-läsning. Object Lock kräver rätt licens och stöds inte med multiprotokollmodellen. Ingen automatisk kopiering mellan dessa bucketval visas.

LabOps IT rekommenderar att dessa val dokumenteras per bucket. Det gör det lättare att förklara varför ett dataset används för applikationsdata medan ett annat används för ett backupmål. En gemensam fysisk lagringspool är inte samma sak som en gemensam åtkomstmodell eller samma återställningskrav.

Versioner och Object Lock har egna licenskrav

Grundläggande S3-stöd presenteras för samtliga TrueNAS-utgåvor. Däremot kräver versionshantering och Object Lock TrueNAS Connect Plus eller ett TrueNAS Enterprise-system, enligt funktionsgenomgången och releaseannonseringen. Man bör alltså inte utgå från att alla avancerade objektfunktioner följer med Community Edition utan ytterligare villkor.

För backupplanering blir det en konkret inköpsfråga. Skriv upp vilken funktion klienten faktiskt behöver, vilken licens som ger den och hur licensen ska hanteras över systemets livslängd. Begär ett aktuellt underlag innan budget beslutas. Den här artikeln fastställer inte pris, avtalslängd eller offlineaktivering.

Skilj också snapshots från objektens versionshantering och retention. De kan bidra till olika återställningsscenarier, men är inte utbytbara benämningar. En pilot bör visa hur en fil eller ett objekt återställs i just den modell som valts, inte bara att en skrivning lyckas.

Den officiella releaseannonseringen den 6 oktober nämner dessutom kosmetiska licensvarningar för vissa Community-licenser via Connect på annan hårdvara än iXsystems. Det är en känd RC-begränsning med angiven omfattning, inte belägg för att all sådan hårdvara saknar fungerande licens.

Så kan en avgränsad pilot utformas

Följande är LabOps IT:s rekommenderade testupplägg, inte leverantörens bekräftelse på kompatibilitet med en viss backupversion. Börja med en separat testinstallation och data som kan återskapas. Ändra inte ett produktionsrepository för att prova en release candidate.

Definiera ett godkänt resultat innan testet startar. För en applikation kan det vara korrekt uppladdning, läsning och återställning av representativa objekt. För backup behöver även återläsning och hantering av avbrutna jobb bedömas. Ett grönt anslutningstest är inte ett bevis på ett fungerande återställningsförfarande.

Testa den faktiska klientversionen, certifikathanteringen och den valda åtkomstmodellen. Dokumentationen är ett underlag för konfiguration, men den ersätter inte klientleverantörens supportbesked. Artikeln verifierar inte någon ny certifiering för Veeam eller andra backupklienter.

Mät med ett representativt urval av objektstorlekar och samtidiga jobb. Redovisa lagringsmedia, nätverk och jämförelsepunkt så att resultatet går att tolka. LabOps IT har inte genomfört egna prestandatester och tillskriver därför inte den nya tjänsten någon uppmätt prestandafördel.

Avsluta piloten med ett återställningstest och ett beslut: fortsätta utvärdera, invänta mognare release eller behålla nuvarande lösning. Spara också det som inte fungerade. Den informationen är ofta mer användbar för driftplaneringen än en sammanställning av tillgängliga funktioner.

LabOps IT:s bedömning

Det inbyggda S3-gränssnittet är en konkret och relevant förändring för lokal lagring. Möjligheten att använda ZFS-plattformens hantering även för objektkonsumenter motiverar en pilot för miljöer som redan har ett tydligt behov. Nyheten är inte att TrueNAS byter årtal, utan att en ny integrationsmodell nu går att prova.

Vår rekommendation är samtidigt att hålla införandet planerat och avgränsat. RC.1-statusen, funktionens separata Early Access-period, licenskraven och begränsningen mellan multiprotokoll och Object Lock måste ingå i beslutet. De är praktiska designvillkor, inte fotnoter.

Den som behöver ett produktionsmål här och nu bör utgå från en stödd och verifierad lösning. Den som planerar nästa års lagringsarkitektur kan däremot använda RC.1 för att samla egna beslutsdata. Det är en rimlig skillnad mellan att bevaka teknisk innovation och att flytta verksamhetskritiska data.

Källor