En ändrad kostnadsgräns för SQL Server
NetApp anger i releaseinformationen för den 12 oktober 2026 att avgifter inte längre tas ut för SQL Server-backup med disk-till-disk eller disk-till-disk fan-out. Backup till objektlagring debiteras däremot fortsatt, bland annat när objektlagring ingår i en 3-2-1-arkitektur. Det är en licens- och kostnadsnyhet, inte ett besked om att all backup eller all lagringskapacitet har blivit gratis.
Den uppdaterade licenssidan, daterad 12 oktober, bekräftar SQL Server-avgränsningen: debiteringen gäller backup till objektlagring. Nyheten kan därför påverka kalkylen för en organisation som redan använder ONTAP-baserad databasbackup utan objektmål. Någon generell besparingsprocent eller automatisk återbetalning framgår inte av de granskade källorna.
LabOps IT:s bedömning är att förändringen motiverar en avtals- och arkitekturkontroll. Den motiverar inte ensam en ombyggnad av fungerande skydd. Börja med att förstå vilka arbetslaster, mål och avtal som finns i den egna miljön innan en ny kostnad förs in i budgeten.
Disk-till-disk och fan-out är olika från objektbackup
NetApps policydokumentation beskriver disk-till-disk som replikering mellan primär och sekundär disklagring. Disk-till-disk fan-out innebär att primärlagringen skickar kopior till flera sekundära diskmål. Objektlagring är ett separat målval och kan vara publik molnlagring eller privat objektlagring.
Det betyder att ordet fan-out inte ensamt avgör debiteringen. Dokumentationen använder även benämningar för 3-2-1-flöden där objektlagring ingår. Kontrollera därför backupolicyns verkliga destinationer i stället för att endast söka efter ett arkitekturnamn i en inventeringslista. En etikett kan vara otillräcklig när flera skyddsnivåer ingår.
SQL Server-översikten skiljer mellan lokala snapshots, replikering till sekundär ONTAP-lagring och backup till objektlager. SnapMirror används för överföring av snapshotbaserade kopior. Dessa är dokumenterade funktioner i tjänsten sedan tidigare; oktoberbeskedets huvudnyhet är den förändrade avgiften, inte att snapshot eller replikering uppfunnits på nytt.
Tjänsteavgift och resurskostnad måste hållas isär
NetApps kostnadsöversikt skiljer mellan resurskostnader och tjänsteavgifter. Objektkapacitet, läsning, skrivning och vissa återställningsoperationer kan ge kostnader hos lagrings- eller molnleverantören. Att en tjänsteavgift ändras tar inte bort den underliggande infrastruktur som behövs för att lagra och återställa data.
LabOps IT rekommenderar att kalkylen därför delas upp i tydliga poster: tjänstens debitering, lagringskapacitet, nätöverföring och arbetet med drift samt återställning. Använd egna avtal och mätvärden. Artikeln fastställer inga nya listpriser för ONTAP, SQL Server, molnresurser eller hårdvara.
För en befintlig kund behöver även avtalets faktiska utformning kontrolleras. Releaseinformationen är inte i sig ett besked om hur redan fakturerade perioder hanteras eller när varje återförsäljares offert ändras. Dokumentera den kommersiella bekräftelsen tillsammans med den tekniska arkitekturen så att en antagen besparing inte blir en obekräftad budgetpost.
Kartlägg rätt arbetslast innan jämförelsen görs
Licenssidan behandlar flera olika arbetslasttyper. SQL Server-beskedet ska inte utan stöd överföras till VMware, Hyper-V, Kubernetes eller alla ONTAP-volymer. En organisation kan använda samma administrationsyta för flera tjänster men ändå ha olika debiteringsförutsättningar för dem.
Börja därför med en förteckning över SQL-instanser och de policyer som faktiskt skyddar databaserna. Anteckna primärsystem, sekundärmål, eventuellt objektmål och vem som äger återställningskravet. Kontrollera även kopplingar till befintliga förvaltningsverktyg och avtal. Detta är LabOps IT:s rekommenderade inventering, inte ett påstående om automatisk upptäckt i varje installation.
Om skyddet importeras från SnapCenter påpekar policydokumentationen att skillnader mellan policyerna kan förekomma. Använd därför den aktuella konfigurationen som underlag. Ett gammalt designbeslut eller en tidigare offert behöver inte beskriva hur den körande backupen ser ut efter senare ändringar.
Ett arbetsflöde för en kontrollerad omräkning
Illustrationen visar en rekommenderad beslutsordning: kartlägg arbetslast och mål, klassificera arkitekturen, räkna om relevanta kostnader och verifiera att återställningskraven fortfarande uppfylls. Det är ett granskningsflöde, inte en bild av hur varje databaspaket färdas i nätverket.
Samla driftansvarig, databasägare och avtalsansvarig kring samma underlag. Driftteamet behöver beskriva vad som faktiskt körs, verksamheten behöver beskriva vad som måste kunna återställas och inköpsfunktionen behöver bekräfta vad som debiteras. Ingen av dessa uppgifter ersätter de andra.
För en pilot är ett bra utfall en dokumenterad jämförelse mellan samma skydd före och efter licensändringen. Håll datamängd, retention och återställningskrav oförändrade i första jämförelsen. Då blir det lättare att skilja en verklig avgiftsförändring från en besparing som egentligen beror på minskat skydd eller kortare historik.
Ta inte bort objektlagring enbart för att undvika avgiften
LabOps IT rekommenderar att backupdesign bedöms mot organisationens behov av historik, separering och återställningsförmåga. Flera kopior är inte automatiskt oberoende om de delar samma administrativa åtkomst eller samma felrisk. Licensbeskedet fastställer ingen universell arkitektur som passar alla organisationer.
Den som överväger ett ändrat mål behöver därför först kontrollera vilka återställningsfall som den befintliga objektkopian täcker. Beslut om att ändra retention eller ta bort ett skyddsmål ska hanteras som en separat förändring. Artikeln rekommenderar inte radering av befintliga backuper eller avveckling av någon kunds objektlager.
Ett kostnadsbeslut behöver också kunna följas upp. Spara vilket underlag som användes och vem som godkände avvägningen. Om verksamhetens krav senare ändras ska det gå att se varför en viss design valdes och vilka förutsättningar som då gällde.
Driftpåverkan och verifiering
En ren kontroll av villkor kräver inte i sig att SQL Server eller backupmiljön byggs om. Om en policy eller arkitektur däremot ändras behövs ett eget underhålls- och testbeslut. LabOps IT har inte installerat någon ny programvara eller mätt avbrottstid i samband med denna granskning.
Verifiera efter en eventuell förändring att scheman, retention och mål motsvarar det godkända beslutet. Genomför en representativ återställning med godkänt testmaterial och kontrollera resultatet tillsammans med databasägaren. En lyckad kopiering eller en grön status i administrationsytan är inte samma sak som en verifierad verksamhetsmässig återställning.
LabOps IT:s bedömning
Förändringen är konkret nog att motivera en genomgång av SQL-backupens kostnader. Den tydligaste vinsten är möjligheten att räkna på samma diskbaserade skydd med en ändrad tjänsteavgift. Vi kan däremot inte fastställa en viss ekonomisk effekt utan kundens avtal, datamängder och mål.
Rekommendationen är planerad kostnads- och arkitekturgranskning, inte akut migration. Behåll återställningskraven, skilj tjänst från resurser och verifiera den egna debiteringen. Det är vår redaktionella slutsats, skild från NetApps produkt- och licensbesked.
Källor
- NetApp Console: ändringar för SQL Server den 12 oktober, händelsedatum 12 oktober 2026; samlingssidan daterad 15 oktober.
- NetApp: licensiering av Backup and Recovery, 12 oktober 2026.
- NetApp: SQL Server-policyer och arkitekturval, 17 september 2026.
- NetApp: skydd av SQL Server-arbetslaster, 2 september 2026.
- NetApp: kostnadsmodell för Backup and Recovery, 19 augusti 2026; äldre bakgrund, den aktuella SQL-specifika licenssidan gäller för artikelns avgränsning.
