Ahogy általában mondani szokták, ha valami balul sül el, akkor az biztosan meg fog történni. Valószínűleg mindenkinek volt már olyan esete, amikor véletlenül törölt egy fontos új fájlt, vagy véletlenül kiemelt és megsemmisített egy szöveget egy szövegszerkesztőben.
Ha Ön egy hoszter vagy webhely tulajdonos, valószínűleg már szembesült felhasználói fiókok vagy saját webhelyének feltörésével. Ilyen esetekben fontos, hogy helyreállítsuk a kronológiát, megtaláljuk a behatolás módját és a sebezhetőséget, amelyet a támadó kihasznált.
Az ilyen problémák megoldására a NILFS2 fájlrendszer tökéletesen alkalmas.
Ez a fájlrendszer a Linux kernelben érhető el a 2.6.30-as verziótól kezdődően.
A fájlrendszer sajátossága, hogy hasonló a verziókezelő rendszerekhez: mindig vissza tudja állítani a rendszer állapotát, és megnézheti, milyen volt egy időben.
Ennek a funkciónak a biztosításához nem szükséges Cron-szkripten beállítania, pillanatfelvételeket készítenie stb. A NILFS2 fájlrendszer mindezt automatikusan elvégzi. Soha nem írja felül a régi adatokat, és mindig új lemezkörökre ír, ha elegendő szabad lemezterület áll rendelkezésre. Teljesen a Copy-on-Write elvének megfelelően.
Valójában bármely fájl módosítása automatikusan új pillanatfelvétel létrehozását vonja maga után, így ezt a fájlrendszert időgépként használhatja, és visszaállíthatja a fájlok állapotát.
Történet
A NILFS2-t a , gyakorlatilag egy állami (mivel többségi tulajdonú) és Japán legnagyobb telekommunikációs cége által fejlesztették. Pontosabban a CyberSpace Laboratories laboratóriumban, Ryusuke Konishi vezetésével. .
A NILFS2 potenciálisan nagyon értékes eszköz a belső biztonsági szolgálatok számára is, mivel lehetővé teszi az összes törölt levél helyreállítását a levelezési adatbázisban, feltárhatja a munkavállalók mulasztásait, akik később megpróbálhatják elrejteni őket, törlés vagy fájljaik módosítása révén.
Hogyan lehet nyomon követni az összes levelezési történetet?
Как можно отследить всю историю перепискиA Linux servers (which is exactly where NILFS2 should be installed for internal security purposes) often utilize a file-based storage method for emails. This is the so-called format . It is enough to install and configure email storage in Maildir. Another format represents a large text file that can be easily parsed into individual messages.
If the mail server uses a database, NILFS2 will allow you to restore the exact timeline of database changes and the ability to recover the database to any of those moments. Then you need to use database tools to see what was in it at that time…
However, something went wrong. Either the Japanese government changed its mind about overseeing everyone (a la the Yarovaya principle), or the performance of NILFS2 on traditional HDDs turned out to be very poor, and NILFS2 was released under the GPL license and quickly incorporated into the Linux kernel, as there were no significant claims against the code written by highly qualified Japanese engineers from the Linux kernel developers.
What is NILFS2 similar to?
In terms of usage: it's like a version control system. Each FS checkpoint is a commit that is made automatically without the user's knowledge whenever there is a change: whether it's deletion, modification of file content, or access rights. Each commit has a number that increases linearly.
From a programmer's viewpoint: it's like a circular buffer. The file system accumulates changes and writes them in chunks of approximately 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 is done sequentially. When free space runs out, the oldest snapshots are deleted, and the chunks are overwritten.
The main benefits of NILFS2
- Versioning!!!
- The procedure for recovering the FS after a crash is straightforward: upon booting, the last chunk with a valid checksum is searched for, and the superblock is installed on it. This is practically instantaneous.
- Due to the fact that writing always occurs linearly:
- it can show good performance results when working on SSDs, with slow random writes.
- NILFS2 saves SSD resources, as there is almost no write amplification factor.
To be precise, it is no more than 2.A lényeg az, hogy a NILFS2 ciklikus újraírásakor a módosítatlan adatokat új darabokba (chunk-okba) helyezi át.Ha a lemezen a módosíthatatlan adatok 10%-a található, akkor egy teljes újraírás során 10%-os írási növekedést kapunk. 50%-os kitöltöttség esetén pedig 50%-os növekedés következik be egy teljes lemez újraírásakor.
A maximális írási fokozás 2. Ez nagyon kicsi figyelembe véve, hogy minden sorban íródik. Összességében az írás multiplexálása kisebb lesz, mint a hagyományos töredezett fájlrendszer esetén 4096 bájt szektornál. ).
- A távoli NILFS2 fájlrendszer replikációjának potenciálisan egyszerű megvalósítása
NILFS2 a /home-hoz
Unix-szerű operációs rendszerekben általában található egy /home mappa, ahol a felhasználói adatok tárolódnak. Különböző programok ebben a mappában mentik el a felhasználóra vonatkozó beállításaikat.
Ki más, ha nem a felhasználók, hibáznak leggyakrabban? Ezért, ahogy mondani szokták, magától értetődő, hogy a /home-on NILFS2-t használjunk.
Főleg, hogy az SSD-k elterjedésével most már nem kell aggódnunk a CoW fájlrendszerek használatakor tapasztalható jelentős teljesítménycsökkenés miatt.
Igen, fájlrendszer pillanatképeket (snapshot-okat) bármilyen gyakorisággal létrehozhatunk a ZFS-ben és a BTRFS-ben, de mindig fennáll a kockázat, hogy egy elveszett fájlváltozás a pillanatképek között marad. Ráadásul a pillanatképeket is adminisztrálni kell: régi pillanatképek törlése. A NILFS2 esetében mindez automatikusan történik, szó szerint néhány másodpercenként.
Létrehoztam egy logikai kötetet az lvcreate segítségével (az nvme csoportban, vékony pool-lal). Azt javaslom, hogy lvm kötetet hozzunk létre, mivel később könnyen bővíthető. Ajánlom, hogy a NILFS2 lemezen a megfelelő verziómélységhez legyen a lemezen 50% szabad hely.
lvcreate -V10G -T nvme/thin -n homeés NILFS2-re formáztam:
mkfs.nilfs2 -L nvme_home /dev/nvme/home
mkfs.nilfs2 (nilfs-utils 2.1.5)
Kezdeti fájlrendszeri adatok írása az eszközre
Blocksize: 4096 Eszköz: /dev/nvme/home1 Eszköz mérete: 10737418240
A fájlrendszer inicializálása sikerült !!
Ezt követően másoljuk át az összes adatot a jelenlegi /home-ból.
Ezt azonnal a számítógép betöltése után tettem, még a fiókomba való belépés előtt, a root felhasználóból. Ha a saját fiókomban lépnék be, néhány program megnyitná a socketeket és a fájlokat a felhasználói mappámban /home/user, ami megnehezítené a tiszta másolást. Mint tudjuk, a root felhasználó otthoni mappája általában a /root útvonalon található, ezért a /home partíción nem nyílnak meg fájlok.
mkdir /mnt/newhome
mount -t nilfs2 /dev/nvme/home /mnt/newhome
cp -a /home/. /mnt/newhome Az utolsó sorral kapcsolatban lásd. .
Most módosítjuk az /etc/fstab fájlt, amelyben a fájlrendszert a /home-ra szereljük fel.
/dev/disk/by-label/nvme_home /home nilfs2 noatime 0 0
Opció noatime szükséges a teljesítmény növelése érdekében, hogy a fájlokhoz való hozzáférés során ne változzon az atime. Ezután újraindítjuk a rendszert.
A NILFS2 snapshot típusai.
A megszokott snapshot, amely nem autómajdó eltávolítással készül, checkpointnak (checkpoint vagy visszaállítási pont) nevezik.
A védelemmel rendelkező snapshotot (snapshot) nevezzük, később csak snapshotnak.
A checkpointok megtekintéséhez az lscp parancsot használjuk.
Snapshotok (snapshotok) megtekintése: lscp -s
Bármikor létrehozhatunk snapshotokat és checkpointokat a következő parancs segítségével:
mkcp [-s] eszközAdatok visszaállítása.
A NILFS lehetővé teszi számunkra, hogy tetszőleges számú régi snapshotot párhuzamosan használjunk a fő FS-vel, de csak olvasási módban.
Mindez így van. A NILFS2 által készített normál checkpointok bármikor automatikusan törölhetők (amikor elfogy a lemezterület, vagy a nilfs_cleanerd szabályai szerint), ezért a mountolás előtt a checkpointot snapshotra kell konvertálni, más szóval rögzíteni kell a snapshotot.
chcp ss checkpoint_számaEzt követően mountolhatjuk a snapshotot, például így:
mount -t nilfs2 -r -o cp=checkpoint_száma /dev/nvme/home /mnt/nilfs/checkpoint_száma Ezután a visszaállítandó fájlokat a snapshotból a /home-ba másoljuk.
Később eltávolítjuk a snapshot elnevezésének tilalmát, hogy a jövőbeli automatikus szemétgyűjtő törölhesse a régi adatokat:
chcp cp checkpoint_számaSegédprogramok a NILFS2-hez
Ezzel problémáink vannak. Igen, természetesen létrehozhatunk FS-t, méretezhetjük online, megtekinthetjük a checkpointok listáját, készíthetünk és törölhetjük azokat. A nilfs2-utils csomag minimális úriemberi felszerelést biztosít.
Mivel az NTT leállította a finanszírozást, nincsenek gyors, alacsony szintű segédprogramok, amelyek lehetővé teszik a fájlok változásainak történetének megjelenítését, vagy a pillanatképek közötti diff létrehozását.
Az én n2u segédprogramom
Ennek az űrnek a betöltésére írtam , amely képes megjeleníteni egy adott fájl/könyvtár változásainak történetét:
n2u log fájlnévA kimenet körülbelül így néz ki:
CHECKPOINT DÁTUM IDŐ TÍPUS MÉRET MÓD
1787552 2019-11-24 22:08:00 első 7079 cp
1792659 2019-11-25 23:09:05 módosítva 7081 cpElég gyorsan működik a választott megvalósítás módja miatt: a fájlok közötti eltéréseket a bisekció módszerével keresi, gyorsan csatolva és összehasonlítva a fájlt/ könyvtárat különböző pillanatképekben.
A pillanatpontok tartományát a kulccsal lehet megadni -cp CP1:CP2 vagy -cp {ÉV-HÓNAP-NAP}:{ÉV-HÓNAP-NAP}.
Ezenkívül megtekinthető a különbség a pillanatpontok között egy adott fájl vagy könyvtár esetében:
n2u diff -r cp1:cp2 fájlnévMegjeleníthetjük az összes változás idővonalát: minden eltérést a pillanatpontok között egy adott fájl/ könyvtár esetében:
n2u blame [-r cp1:cp2] fájlnévA dátumtartomány e parancs esetében is támogatott.
Felhívás a fejlesztőknek
A Habrán sok szakértő van. Kérem, finomítsátok a NILFS2-t. Készítsetek replikációt, alacsony szintű gyors diff-et a verziók között, reflinket és egyéb funkciókat!
Hivatkozások
.
Tárhelyek:
.
.
Hírek:
. Az azonosító a feliratkozáshoz: linux-nilfs.
.
.
.
Köszönetnyilvánítás:
- A NILFS2 fejlesztői: Ryusuke Konishi, Koji Sato, Naruhiko Kamimura, Seiji Kihara, Yoshiji Amagai, Hisashi Hifumi és Satoshi Moriai. Egyéb jelentős hozzájárulók: Andreas Rohner, Dan McGee, David Arendt, David Smid, dexen deVries, Dmitry Smirnov, Eric Sandeen, Jiro SEKIBA, Matteo Frigo, Hitoshi Mitake, Takashi Iwai, Vyacheslav Dubeyko.
- Az Amblin Entertainment és a Universal Pictures cégeknek a csodálatos filmsorozatért . A poszt első képe a Vissza a jövőbe — 3. című filmből származik.
- A cégnek a támogatásért és a lehetőségért, hogy a blogomban publikálhassak a Habr-on.
P.S. A megjegyzett hibákat kérlek privát üzenetben küldjétek el. Ezzel növelem a karmámat.
Kísérletezhet a NILFS2-vel, ha a lenti kupont felhasználva virtualizált gépet rendel. Új ügyfeleknek 3 napos ingyenes próbafeltétel.
Forrás: habr.com
