Två förändringar som möts i återställningen
NetApp redovisar den 21 september 2026 en uppdatering av Backup and Recovery för Kubernetes-arbetslaster. Den omfattar Trident Protect 26.09, åtkomststyrning på kluster- och namespacenivå samt återställning eller nedladdning av enskilda filer och mappar från VM-baserade applikationer. Versionsinformationen uppdaterades den 23 september. Funktionerna beskrivs som delar av den aktuella releasen; dessa tre punkter är inte märkta som förhandsversioner. Versionsinformationen är den centrala källan till förändringen.
För infrastrukturspecialister är kombinationen mer intressant än versionsnumret. När virtuella maskiner drivs i Kubernetes behöver återställningsansvaret kunna följa samma organisatoriska gränser som applikationerna. Ett driftteam kan behöva återställa en fil åt en tjänsteägare utan att samtidigt få rätt att ändra skyddet för andra team. Den redaktionella slutsatsen är att återställningsfunktion och behörighetsmodell måste provas tillsammans.
Enskilda filer i stället för hela applikationen
Den nya funktionen kräver minst en återställningspunkt och en VM-partition med ett stödd filsystem. NetApps instruktion anger uttryckligen att återställning och nedladdning för närvarande bara stöds från lokal snapshot. Det är en central avgränsning: att miljön också har objektlagringsbackup innebär inte att den nya filfunktionen kan läsa den kopian. Återställning till VM skriver dessutom över befintliga filer som standard.
NetApp listar Windows Server 2022, Windows 10 och Windows 11 samt Ubuntu 22.04, RHEL 9, Fedora 39, CentOS Stream 9 och openSUSE Leap 15.6 som stödda gäster. De angivna filsystemen är BTRFS, exFAT, ext4, NTFS och XFS. Destinationen måste vara igång, ha en IP-adress och tillåta att användaren skriver till återställningsplatsen. SSH med lösenordsautentisering krävs; enbart nyckelbaserad inloggning stöds inte. Windowsgäster behöver en aktiverad OpenSSH-server.
Nedladdningsvägen skiljer sig praktiskt från direkt återställning. Valda filer sparas i ett tar-arkiv via webbläsaren, och gästuppgifter behövs inte för nedladdningen. Båda vägarna dokumenteras i NetApps instruktion för filer och mappar.
I en lokal pilot bör de två vägarna därför behandlas som olika driftoperationer. Nedladdning kan passa när innehållet behöver kontrolleras innan det återförs. Direkt återställning kan passa när den avsedda destinationen och filversionen redan är fastställda. Det är LabOps IT:s rekommenderade arbetsordning, inte ett löfte om att nedladdning ersätter alla återställningsscenarier. Mät också operatörstid och kontrollarbete; leverantören anger ingen generell tidsvinst för den egna miljön.
Namespace blir en tydligare behörighetsgräns
Vid klusterupptäckt kan ett kluster kopplas till ett projekt eller en mapp i NetApp Console. Enskilda namespaces kan registreras som IAM-resurser och kopplas till motsvarande organisatoriska scope. Backup and Recovery-rollen inom detta scope avgör sedan vilka handlingar användaren får utföra. Detta beskrivs i dokumentationen för Kubernetes-åtkomst, daterad den 17 september.
Rollerna skiljer på visning, skydd och återställning. Viewer får visa men inte skapa, skydda eller återställa. Backup Admin kan skapa applikationer och konfigurera skydd men inte återställa. Restore Admin kan visa och återställa men inte skapa applikationer eller skyddspolicyer. Super Admin har den bredare kombinationen. Clone Admin används inte för Kubernetes-arbetslaster.
En detalj påverkar användbarheten: när resurserna kopplas till en mapp behövs även Viewer på projektet som är valt i projektväljaren för att öppna tjänstens startsida. Mappens roll styr vad användaren därefter kan göra. Ett namespace som registreras utan vald mapp eller projekt blir däremot inte automatiskt kopplat till något av dessa scope.
Organisationen behöver därmed bestämma ägarskap före utrullning. Börja med två testnamespaces och separata användare. Prova både tillåtna och otillåtna operationer: rätt användare ska kunna återställa inom sitt ansvar, medan samma konto ska nekas motsvarande åtgärd utanför gränsen. Dokumentera utfallet så att åtkomstmodellen kan granskas när team eller projekt förändras.
Kontrollera hela integrationskedjan
NetApps aktuella kravlista, daterad den 21 september, kräver ett primärt ONTAP-system för Kubernetes-skydd och utesluter ASA r2 i detta sammanhang. Den anger Trident 25.06–26.06 och Trident Protect 26.08 eller senare. Stödda Kubernetesdistributioner och versioner hänvisas vidare till Trident Protects supportomfattning. Console-agenten bör enligt NetApp ha statisk IP-adress, och utgående TCP 443 mellan klustret, connectorn och proxyn måste vara tillgänglig.
Kravlistan och releaseinformationen beskriver olika delar av kedjan: Trident är lagringsintegrationen, medan Trident Protect hanterar applikationsskyddet. Läs därför inte versionsnumret 26.09 som att samtliga komponenter automatiskt ska få samma version. Kontrollera den installerade kombinationen mot respektive stödlista före ändring.
En rimlig inventering omfattar lagringsplattform, Kubernetesdistribution, Trident, Trident Protect, agentplacering och gästsystem. Koppla varje uppgift till den applikation som ska provas. Då blir det tydligare om ett misslyckat test beror på backupdata, gästautentisering, nätverksåtkomst eller användarens roll.
Prioriterad pilot före produktionsändring
LabOps IT rekommenderar planerad prioritet för miljöer som redan använder NetApp för VM-applikationer i Kubernetes. Börja med att verifiera att den avsedda återställningspunkten verkligen är en lokal snapshot och att testgästens operativsystem och filsystem finns i stödlistan. Skapa testfiler med känt innehåll och dokumentera vilken version återställningen ska ge.
Prova därefter nedladdning, granska arkivets innehåll och jämför mot testfilernas kontrollsummor. Prova direkt återställning till en avsedd testdestination och bekräfta vad som händer med en redan befintlig fil. Använd konton med den minsta roll som behövs och kontrollera samtidigt att andra namespaces inte blir åtkomliga.
Det här är ett föreslaget acceptansprov, inte en rapport om ett genomfört LabOps-test av produkten. Bedöm också hur lösenordsbaserad SSH passar organisationens gästpolicy och hur återställningsuppgifter förvaltas. Godkänn inte en generell ändring av gästernas åtkomstmodell enbart för att en enskild återställning lyckades i labbet.
LabOps IT:s bedömning
Vår bedömning är att uppdateringen ger konkret nytta när en avgränsad fil behöver återföras utan att hela VM-applikationen återställs. Den mer precisa rollfördelningen kan samtidigt göra det lättare att dela återställningsansvar mellan centralt driftteam och applikationsägare. Nyhetsvärdet ligger i den kombinationen, inte i att backupplattformen har fått ännu en release.
Den viktigaste begränsningen är kopplingen till lokal snapshot. Planera separat för scenariot där det primära systemet eller den lokala kopian saknas. Ett godkänt filåterställningsprov visar att just den vägen fungerar; det bevisar inte att hela katastrofåterställningsplanen är tillräcklig. Produktionsbeslut bör därför bygga på dokumenterad kompatibilitet, verifierad åtkomst och provade återställningsvägar för de fel verksamheten faktiskt behöver klara.