Zoals bekend, als er iets mis kan gaan, dan zal het ook gebeuren. Waarschijnlijk heeft iedereen wel eens meegemaakt dat een belangrijk bestand per ongeluk is gewist of dat tekst in een tekstverwerker onbedoeld is geselecteerd en verwijderd.
Als je een hoster of website-eigenaar bent, ben je waarschijnlijk geconfronteerd met gehackte gebruikersaccounts of je eigen site. In zulke gevallen is het belangrijk om de chronologie te herstellen, de inbraakmethode en de kwetsbaarheid die door de aanvaller is gebruikt te achterhalen.
Voor het oplossen van dergelijke problemen is het NILFS2-bestandssysteem zeer geschikt.
Het is aanwezig in de Linux-kernel sinds versie 2.6.30.
Een kenmerk van dit bestandssysteem is dat het lijkt op een versiebeheersysteem: je kunt altijd de toestand van het systeem terugdraaien en bekijken hoe het een tijdje geleden was.
Voor het waarborgen van deze functionaliteit hoef je geen Cron-scripts in te stellen, snapshots te maken, enzovoorts. Het NILFS2-bestandssysteem doet dit allemaal zelf. Het overschrijft nooit oude gegevens en schrijft altijd naar nieuwe schijven als er voldoende vrije schijfruimte beschikbaar is. Dit is volledig in overeenstemming met het Copy-on-Write-principe.
Eigenlijk leidt elke wijziging in een bestand automatisch tot het maken van een nieuwe snapshot van het bestandssysteem, zodat je dit bestandssysteem als een tijdmachine kunt gebruiken en de staat van bestanden kunt terugdraaien.
Geschiedenis
NILFS2 is ontwikkeld in de schoot van , feitelijk, een staatsbedrijf (het heeft een controlepakket) en de grootste telecommunicatiebedrijf van Japan. Meer specifiek in het CyberSpace Laboratories onder leiding van .
Het is onbekend waarvoor het precies ontwikkeld is, maar men kan vermoeden dat zo'n bestandssysteem met zijn 'tijdmachine'-functionaliteit ideaal is voor de opslag van gegevens waar speciale diensten mogelijk in willen spitten, om de hele historie van sms'jes, e-mails, enzovoorts opnieuw af te spelen.
NILFS2 is ook potentieel een zeer waardevol instrument voor interne veiligheidsdiensten, omdat het het mogelijk maakt om alle verwijderde e-mails in een database te herstellen, en om fouten van medewerkers te onthullen die mogelijk hebben geprobeerd deze te verbergen door hun bestanden te verwijderen of aan te passen.
Hoe je de hele geschiedenis van correspondentie kunt volgenIn Linux servers (which is precisely where NILFS2 should be installed for internal security purposes), emails are often stored using a file-based approach. This is known as the . It's sufficient to install the and configure email storage in Maildir. Another format, , consists of a large text file that can be easily parsed into individual messages.
If the mail server uses a database, NILFS2 will allow for an accurate timeline of database changes and provide the ability to restore the database at any of these moments. Then, one must use database tools to see what was in it at that time...
However, something went wrong. Perhaps the Japanese government changed its mind about monitoring everyone (like the Yarovaya principle), or the performance of NILFS2 on traditional HDDs proved to be subpar, and NILFS2 was released under the GPL license and quickly integrated into the Linux kernel, as the kernel developers had no significant complaints about the code written by highly qualified Japanese programmers.
What is NILFS2 similar to?
In terms of usage: it resembles a version control system. Each checkpoint in the FS is a commit that is made automatically without the user's knowledge upon any change: whether it's deletion, modification of file content, or change of permissions. Each commit has a number that increases linearly.
From a programmer's perspective: it's like a circular buffer. The file system accumulates changes and writes them to chunks roughly equal to 8 MB (2000 * 4096, where 2000 is the number of elements in a block, and 4096 is the page size in memory). The entire disk is divided into such chunks. Writing occurs sequentially. When free space runs out, the oldest snapshots are deleted, and chunks are overwritten.
Key benefits of NILFS2
- Versioning!!!
- The procedure to recover the FS after a crash is straightforward: upon booting, the last chunk with a valid checksum is found, and the superblock is set on it. This is practically an instantaneous operation.
- Due to the fact that writing always occurs linearly, it can yield good results when used on SSDs with slow random writes.
- NILFS2 conserves SSD resources as the write amplification factor is almost nonexistent.
- To be precise, it is no more than 2.
Specifieker gezegd, hij is niet meer dan 2.Het is zo dat bij de cyclische herschrijving van de hele schijf NILFS2 onveranderlijke gegevens naar nieuwe blokken (chunks) verplaatst.Als we 10% onveranderlijke gegevens op de schijf hebben, krijgen we 10% meer schrijfruimte bij 1 volledige herschrijving. En 50% meer bij 50% vullen van het apparaat voor 1 volledige herschrijving van de schijf.
De maximale versterkingsfactor van de schrijfbewerking is 2. Dit is erg laag gezien het feit dat alles sequentieel wordt geschreven. Over het algemeen zal de schrijfvermeerdering minder zijn dan bij een gewone gefragmenteerde FS met een sector van 4096 byte. ).
- Potentiƫle eenvoud van het implementeren van replicatie naar een externe NILFS2 FS
NILFS2 voor /home
In Unix-achtige besturingssystemen is er gewoonlijk een map /home waarin gebruikersgegevens worden opgeslagen. Verschillende programma's slaan hun instellingen die verband houden met specifieke gebruikers in deze map op.
Wie, als niet de gebruikers, maakt er het vaakst een puinhoop van? Daarom is het, zoals ze zeggen, een kwestie van God om NILFS2 op /home te gebruiken.
Bovendien hoeven we ons met de wijdverspreide verspreiding van SSD's geen zorgen meer te maken over sterke dalingen bij het gebruik van CoW-bestandssystemen.
Ja, we kunnen snapshots van de FS (sne snapshots) zo vaak maken als we willen in ZFS en BTRFS, maar er is altijd het risico dat een verloren wijziging van een bestand tussen de snapshots komt te zitten. En snapshots moeten ook beheerd worden: oude verwijderen. In NILFS2 gebeurt dit automatisch, letterlijk elke paar seconden.
Ik heb een logisch volume aangemaakt met behulp van lvcreate (in de groep nvme volume, thin pool). Ik raad aan om precies op het volume lvm te creƫren, omdat het later gemakkelijk kan worden vergroot. Ik raad aan om 50% vrije ruimte op de schijf met NILFS2 te hebben voor een behoorlijke diepte van versiebeheer.
lvcreate -V10G -T nvme/thin -n homeen heb het geformatteerd in NILFS2:
mkfs.nilfs2 -L nvme_home /dev/nvme/home
mkfs.nilfs2 (nilfs-utils 2.1.5)
Begin met het schrijven van de initiƫle gegevens van het bestandssysteem naar het apparaat
Blockgrootte: 4096 Apparaat: /dev/nvme/home1 Apparategrootte: 10737418240
Bestandssysteeminitialisatie geslaagd !!
Daarna moet je alle gegevens van de huidige /home kopiƫren.
Ik deed dit onmiddellijk na het opstarten van de computer, voordat ik in mijn account inlogde, als gebruiker root. Als ik onder mijn gebruikersaccount was ingelogd, zouden bepaalde programma's sockets en bestanden in de map van mijn gebruiker /home/user hebben geopend, wat een schone kopie moeilijk zou maken. Zoals bekend bevindt de thuismap voor de gebruiker root zich meestal op het pad /root, daarom zullen er geen bestanden worden geopend op de partitie /home.
mkdir /mnt/newhome
mount -t nilfs2 /dev/nvme/home /mnt/newhome
cp -a /home/. /mnt/newhome Wat betreft de laatste regel zie. .
Vervolgens bewerken we /etc/fstab, waarin het bestandssysteem voor /home wordt gemount, op
/dev/disk/by-label/nvme_home /home nilfs2Ā Ā noatime 0 0
OptieĀ noatime is nodig voor prestatieverbetering, zodat de atime niet wordt gewijzigd bij elke toegang tot bestanden. We herstarten daarna.
Soorten snapshots in NILFS2.
Een gewone snapshot zonder bescherming tegen verwijdering wordt een checkpoint (checkpoint of herstelpunt) genoemd.
Een snapshot met bescherming tegen automatische verwijdering wordt een snapshot genoemd, verder gewoon een snapshot.
Het bekijken van checkpoints gebeurt met het commando lscp
Snapshots (snep shots) bekijken lscp -s
We kunnen zelf op elk moment snapshots en checkpoints aanmaken met:
mkcp [-s] apparaatWe herstellen gegevens.
NILFS stelt ons in staat om zoveel oude snapshots parallel aan de werking met de hoofdvertakking van het bestandssysteem te monteren. Maar alleen in de leesmodus.
Het is zo ingericht. Gewone checkpoints die NILFS2 maakt, kunnen op elk moment automatisch door het systeem worden verwijderd (wanneer de schijfruimte opraakt of volgens de regels van nilfs_cleanerd), daarom moeten we voordat we monteren het checkpoint in een snapshot omzetten of, in het Russisch, de snapshot vastleggen.
chcp ss checkpoint_nummerDaarna kunnen we de snapshot bijvoorbeeld zo monteren:
mount -t nilfs2 -r -o cp=checkpoint_nummer /dev/nvme/home /mnt/nilfs/checkpoint_nummer Daarna kopiƫren we de te herstellen bestanden van de snapshot naar /home.
Vervolgens verwijderen we de niet-verwijderbaarheidsvlag van de snapshot, zodat de automatische afvalverzameling in de toekomst verouderde gegevens kan verwijderen:
chcp cp checkpoint_nummerHulpmiddelen voor NILFS2
Daar hebben we een probleem mee. Ja, natuurlijk kunnen we een FS maken, de grootte online wijzigen, de lijst met checkpoints bekijken, ze maken en verwijderen. Het pakket nilfs2-utils biedt de minimale gentlemen's set.
Aangezien NTT het financieren heeft stopgezet, zijn er geen snelle lage-niveau hulpprogramma's beschikbaar om de wijzigingsgeschiedenis van bestanden weer te geven of om diff's tussen momentopnames te maken.
Mijn hulpprogramma n2u
Om deze vacuĆ¼m in te vullen heb ik geschreven , dat in staat is om de wijzigingsgeschiedenis van een specifiek bestand/map weer te geven:
n2u log bestandsnaamDe uitvoer ziet er ongeveer zo uit:
CHECKPOINT DATUM TIJD TYPE GROOTTE MODUS
1787552 2019-11-24 22:08:00 first 7079 cp
1792659 2019-11-25 23:09:05 changed 7081 cpHet werkt vrij snel voor de gekozen implementatiemethode: het zoekt naar verschillen tussen bestanden met behulp van bissectie, door bestanden/mappen snel te monteren en te vergelijken in verschillende momentopnames.
U kunt een bereik van checkpoints opgeven met de sleutel -cp CP1:CP2 of -cp {JAAR-MAAND-DAG}:{JAAR-MAAND-DAG}.
U kunt ook het verschil tussen checkpoints voor een specifiek bestand of map bekijken:
n2u diff -r cp1:cp2 bestandsnaamU kunt de volledige wijzigingsgeschiedenis weergeven: alle verschillen tussen checkpoints van een specifiek bestand/map:
n2u blame [-r cp1:cp2] bestandsnaamHet datumbereik in deze opdracht wordt ook ondersteund.
Oproep aan ontwikkelaars
Op Habr zijn veel specialisten. Ik verzoek u om NILFS2 verder te verbeteren. Maak replicatie, snelle lage-niveau diff's tussen revisies, reflink en andere functies!
Links
.
Repositories:
.
.
Nieuwsbrieven:
. Identificatienummer voor abonnement linux-nilfs.
.
.
.
Thanks to:
- Aan de ontwikkelaars van NILFS2: Ryusuke Konishi, Koji Sato, Naruhiko Kamimura, Seiji Kihara, Yoshiji Amagai, Hisashi Hifumi en Satoshi Moriai. Andere belangrijke bijdragers zijn: Andreas Rohner, Dan McGee, David Arendt, David Smid, dexen deVries, Dmitry Smirnov, Eric Sandeen, Jiro SEKIBA, Matteo Frigo, Hitoshi Mitake, Takashi Iwai, Vyacheslav Dubeyko.
- Aan de bedrijven Amblin Entertainment en Universal Pictures voor de geweldige filmserie . De eerste afbeelding in de post is afkomstig uit de film Ā«Terug naar de Toekomst ā 3Ā».
- The company for the support and the opportunity to publish in their blog on Habra.
P.S. Report any noticed errors privately. I will raise your karma for this.
U kunt experimenteren met NILFS2 door een virtuele machine te bestellen bij met de coupon hieronder. Voor alle nieuwe klanten is er een gratis proefperiode van 3 dagen.
Bron: habr.com
