Windows på väg få nytt filsystem

Men precis, det stämmer väl ganska bra överens med det jag vill framföra. Det hade börjat konvergera ganska starkt mot ett OS för alla, men man var inte riktigt där än. Det bevisas väl också ytterligare av Windows ME, som ju implicit skulle vara ett OS för ingen om W2k var ett OS för alla.

Körde också 98SE tills jag skaffade en 1.2GHz Tbird-bestyckad burk med massor av RAM, fritt ur minnet ungefär ett halvår efter W2k släpptes.

Det finns dock (open source) tredjepartsverktyg som fungerar genom att de skippar versionskontrollen men i övrigt använder sammma API:er etc. som det inbyggda formateringsverktyget i Windows om man vill experimentera med ReFS på en vanlig konsumentversion av Windows.

Sannolikt på grund av licensens på dessa andra filsystem.

Skulle inte bli förvånad om det inte är samma hybris som filmfolk som skall göra en nyversion av en klassiker.
"Det här kan jag göra bättre!"

[cloudy@helios ~]$ sudo lsblk -f
NAME                  FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda                   LVM2_member LVM2 001       wNmXDo-DzY8-ef7t-9eHM-MOmn-QAj3-nCoN2Y
└─helios--ssd-storage xfs                        c9261f13-8dcd-45c6-9fbc-b3c2ac9e495e
sdb                   LVM2_member LVM2 001       wxmsg4-U5np-fTLj-HBsd-y8og-uoap-k7wX2E
└─helios--ssd-storage xfs                        c9261f13-8dcd-45c6-9fbc-b3c2ac9e495e
zram0                 swap        1        zram0 dd04b916-23bc-4500-9603-5b0ff0d558ff                  [SWAP]
nvme1n1
├─nvme1n1p1
├─nvme1n1p2           ntfs                       9456CB4256CB23B8
└─nvme1n1p3           ntfs                 Luna  2C88ED2088ECE8F2
nvme0n1
├─nvme0n1p1           vfat        FAT32          85CF-3893                               795.6M    22% /boot
└─nvme0n1p2           crypto_LUKS 2              862665eb-3880-4a66-a562-24c4f538401c
  └─main              btrfs                      6d50061b-195d-40af-b475-fb6cd2d83bb6    407.1G    14% /home
                                                                                                       /
[cloudy@helios ~]$ mount -t btrfs
/dev/mapper/main on / type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=262,subvol=/timeshift-btrfs/snapshots/2025-03-29_03-16-46/@)
/dev/mapper/main on /home type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@home)

Hur skyddar snapshot emot ransomware?

Microsoft lever ekonomiskt på sina NTFS rättigheter. Det är det som gjort hela jobbet åt MS AD, vilket är den största släggan Microsoft har i företag, och i princip grundbulten i 365. Att microsoft skulle köra ett allmänt filsystem som dom inte styr är helt emot deras affärsmodell

Så länge som ransomware inte kör som root så kan det ta bort en användares filer, men inte snapshots på dem.

Man bör förstås ha backups också, dock!

Edit: Detta kanske inte är sant för btrfs -- vet inte om användare kan ta bort snapshots på sina filsystem där. Med ZFS kan man det inte som standard.

Ni båda säger direkt att rättigheter stoppar ransomware, det har juh inget med snapshot att göra?

Snapshot är en differans på en fil. Ganska oanvändbar om man ransomwerat orginalfilen?

Nja, det beror på hur du menar. En snapshot lagras som bara den data som skiljer, men det är inget man behöver bry sig om som användare -- man kan lika gärna se det som att en snapshot kopierar all data, för det beter sig exakt likadant.

Det vill säga: om dina filer blir krypterade av ransomware så kan du återställa till ett snapshot innan det hände, så återställs allting.
Eller så kan du (iaf med ZFS) kopiera dem från en snapshot även utan att behöva återställa filsystemet; det gör jag rätt ofta när jag behöver äldre filer. De ligger i en "virtuell mapp" (.zfs/snapshot) på varje filsystem, så det är bara bläddra fram till en fil/mapp och kopiera dem dit man vill.

*räcker upp handen*

Tar dock bara offline-backups en gång per månad, och även det känns onödigt.
Har först datan på min dator, sedan flera backups till min NAS och offsite-server. Båda de kör snapshots (separat), och all data från NAS:en klonas till offsite-servern. Så jag har snapshots på mina backups lokalt och offsite.
Och så är det förstås överföring dit på ett sätt som inte har rättighet att ta bort snapshots, så om min NAS skulle bli hackad hjälper det inte alls i att ta bort datan från offsite-servern. (Dvs root på NAS:en kan inte ta bort något offsite.)

Vad filsystemet presenterar för dig efter att du tagit ett snapshot är skillnaden mot originalfilen efter att snapshot skapades. Från filkonsumentens sida (oavsett om det är något du själv avser att göra eller ett malware du triggat) är det originalfilen. Det är bara om du har rätt att modifiera filsystemets metadata som du har möjlighet att förstöra den verkliga originalfilen.

All väldesignad säkerhet består av multipla lager som vart och ett kan ha kända eller okända svaga punkter. Poängen är att sammantaget är det svårt att omintetgöra den. Använder du snapshots som ett skyddande lager, men kör malware i kontexten av en användare som får lov att radera snapshots, så är det upp till malwareskaparens kompetens/illvilja om du har något som helst skydd. Det är som att ha ett bra backupschema, men bara till en ständigt inkopplad USB-hårddisk. Men ju fler abstraktionslager du lägger mellan en angripare och vad de försöker förstöra desto jobbigare blir det för dem att lyckas - och desto större chans att din data kan återställas med minimalt obehag.

plus att enda problemet med btrfs i raid5/6 är samma (write hole) som alla som kör RAID utan batteri på disk-kontrollern (och de som kör ZFS) lever med (mdraid har visst skydd iom bitsets, men det är inte 100%).

Vänta nu här. Jag vill minnas att ReFS fanns i Windows 10 Pro för länge sedan, men Microsoft plockade bort stödet i en uppdatering. Har för övrigt kört med ReFS i Window Server, men såg inga direkta föredelar. Det var mest långsammare än NTFS, kunde upptäcka bitfel men inte automatiskt korrigera dem. Sedan hade de sitt påhit med Windows Storage Spaces för att skapa en diskpool som var bra i teorin, men så segt att det knappt gick att använda. Numera känns det som att de inte vill att man ska köra Windows Server utan allt ska in i Azure molnet.

Finns relativt billiga hemma-ups:ser man kan sätta på datorn och sedan få en någonlunda "gracefull shutdown".

T.ex. en sådan här https://www.inet.se/produkt/6302465/apc-back-ups-750-va
USB-kabel, mjukvara, så är det lite säkrare iaf.

Verkligen fascinerande hur länge NTFS har hängt med. Minns när man envist stannade på FAT32 för det var marginellt snabbare men till slut fick man ge med sig.

Känns som NTFS och IPv4 kommer vara konstanter under hela min livstid...verkar helt omöjligt att göra sig av med detta bagage.

Nja, den krypterade filen är ju en diff mot den ursprungliga okrypterade filen. Däremot är en snapshot inte en backup oavsett så det är ju bra att ha riktiga backuper med om man bryr sig om sin data. Snapshots hjälper ju föga om disken rasar.

Nä du har helt rätt. Ville bara veta hur folk resonerar när dom säger att snapshot skyddar emot ransomware. I mina ögon är det farligt att säga så då i praktiken är en snapshot mest trams för att ge dig det Microsoft kallade för Shadow Copy eller det jag personligen kallar för versions historik, något som i princip duger emot klantiga användare på ett företag, men inte mer. Men har på senare tid sätt att folk/företag pratar väldigt varm om Snapshot som någon problemlösare i ett större sammanhang.

Som jag antydde i mitt tidigare inlägg: Snapshots på en maskin är bara så säkra som maskinen själv är. Snapshots på ett lagringsområde som används av en maskin men inte kontrolleras av den är ytterligare några snäpp säkrare. Med lite mer avancerade SAN är detta något som ofta nämns av säljare (men i mindre balanserade termer, naturligtvis).

Vad du vinner med snapshots är huvudsakligen smidig återställning - oftast smidigare än via backupverktyget du ändå förhoppningsvis använder i dina miljöer. Någon som föreslår att du kan skippa backuper om du har snapshots vill dig troligen inte väl. Någon som säger att snapshots i sig själva är backuper är inte en person du bör lyssna på.

Men som ytterligare ett lager av lättillgängligt skydd mot några av de vanligaste kategorier av dataförlust är de fantastiska. Och rätt planerade samt placerade - i klartext: klonade till fysiskt separat lagring på en fysiskt separat maskin - kan de definitivt fungera som en av dina backupmetoder.

Säkert fixat när windows 15 kommer 🤣🤣🤣

Ptja jag vet inte om du får så mycket medhåll på att snapshots bara är trams. Det har ju väldigt stora användningsområden för att kunna rulla tillbaka ändringar även i t.ex. vmware eller andra hypervisors, och det är ett väldigt effektivt sätt att ha versionshistorik vilket är en större vinst för många än vad du vill påskina här. Jag använder det ofta när jag lyckas konfigurera sönder saker på min egen dator. Bara rulla tillbaka en snapshot från gårdagen så har man ett nytt grundscenario att utgå ifrån snarare än att behöva hålla koll på exakt allt man gjort och ändra tillbaka manuellt överallt. Det är också otroligt snabbt att ta en snapshot jämfört mot att ta en riktig backup, och framförallt gäller det åt andra hållet när du ska återställa ändringar.

Snapshots är ju bra, men kan ju ändå bli krångligt med Ransomware som man har för liten disk för att klara att alla filer som krypteras ska vara snapshottade, vet inte hur bra Windows 11 klarar att systemdisken blir helt full och man sedan ska boota om och backa snapshots. Men det kanske går bra. Systemdisken är ju inte aktuell nu. MacOS brukar, apropå ingenting helt balla ur om man fyller systemdisken.

Apropå NTFS var det ändå ett gigantiskt lyft mot fat32, jag körde WinNT4, Win2K och XP på gamla härkar hellre än Win98 eller Me.

om du läser länken du själv skickade så anger de enabart write hole som något som kan förstöra data. De andra är "småproblem" som att scrub sänker prestandan "mer än det borde".

Glöm inte den stora varningen ”lägg inte metadata på RAID5/6”. Jag vet inte hur du tolkar det, men jag drar som sagt den samlade slutsatsen att du inte ska ha något av värde på btrfs i den konfigurationen eftersom det bara är en tidsfråga innan det inte är tillgängligt längre, och att det sedan mycket väl kan vara en fråga om oacceptabel neretid innan det är tillgängligt igen om det finns något att rädda. Det känns som en onödig risk att ta när det finns kända sätt att inte utsätta sig för den.
(Och om du är ett fan av detta filsystem, glöm inte att ett av de sätten är att visserligen använda btrfs men inte i just en av dessa paritetskonfigurationer).