Снимке су важне без обзира да ли на кућном рачунару користите једноставну виртуелну машину или је то база података предузећа која се стално ажурира и модификује. Важно је имати снимке, односно копију целокупног система датотека какав је био у датом временском периоду.

Људи често изгубе појам о томе где су ствари кренуле по злу, датотека је избрисана и нико није приметио да је нестала. Неколико резервних копија је прошло и сада схватате да важна датотека недостаје свим доступним сигурносним копијама у последњих 5 недеља. У овом упутству ћемо видети како се користе ЗФС снимци и дотакнуће се различитих политика снимања које би функционисале оптимално, како у погледу коришћења ресурса, тако и надокнадивости.

Механизам копирања на писање

ЗФС има и преглед датотека и директорија на високом нивоу и разуме како се подаци записују на диск. Када физички записујете податке на диск, то се ради у дискретним блоковима. Типично, величина блока може бити и до 1 МБ, али подразумевано је обично 128 КБ. То сада значи да ће се свака модификација (читање, писање или брисање) десити у дискретним блоковима.

Механизам цопи-он-врите осигурава да кад год се блок модификује, уместо да га директно модификује, направи копију блока са потребним модификацијама урађеним на новом блоку.

Ово је посебно корисно у случајевима када, рецимо, дође до нестанка струје и систем се сруши док су нови подаци уписивани на диск. Ако се то догоди у традиционалном систему датотека, датотеке ће се оштетити или остати рупе у њима. Али ако користите ЗФС, можете изгубити текућу трансакцију јер се то догађало, али последње важеће стање датотека и даље ће остати нетакнуто.

Снимке се такође ослањају на ову функционалност, и то у великој мери у ствари. Када направите снимак датог скупа података („скуп података“ је ЗФС израз за систем датотека), ЗФС само бележи временску ознаку када је направљен снимак. То је то! Подаци се не копирају и не троши се додатна меморија.

Тек када се систем датотека промени и подаци у њему одступе од снимка, снимак почиње да троши додатно складиште. Оно што се дешава испод хаубе је следеће - Уместо да старе блокове временом рециклира, ЗФС их задржава. Ово такође побољшава искоришћеност складишта. Ако направите снимак скупа података од 20 ГБ и ту и тамо измените само неколико текстуалних датотека, снимак може заузети само неколико МБ простора.

Прављење снимака

Да бисмо демонстрирали употребу снимака, почнимо са скупом података који садржи пуно текстуалних датотека, само да ствар буде једноставна. Виртуелна машина коју ћу користити за демонстрацију ради на ФрееБСД 11.1-РЕЛЕАСЕ-п3 што је најновије стабилно издање доступно у време овог писања. Коренски систем датотека је монтиран на зроот подразумевано обједињује и мноштво познатих директоријума попут / уср / срц, / хоме, / итд су сви њихови сопствени скупови података монтирани зроот. Ако не знате шта значи базен (или зпоол), у ЗФС народном језику било би добро прочитати га пре него што наставите.

Један од многих система датотека или скупова података који подразумевано долазе на ФрееБСД је: зроот / уср / срц

Да бисте погледали његова својства, покрените следећу наредбу.

[заштићена е-поштом]: ~ $ зфс лист зроот / уср / срц

Као што видите, користи 633 МБ простора за складиштење. Садржи цело стабло извора за оперативни систем.

Направимо снимак зроот / уср / срц

[заштићен е-поштом]: ~ $ зфс снапсхот зроот / уср / [заштићен е-поштом]

Симбол @ делује као граничник између скупа података и имена снимка, што је у нашем случају снапсхот1.

Погледајмо сада стање снимка како је створен.

Покретањем наредбе:

зфс лист -рт све зроот / уср / срц

Можете видети да снимак не користи додатни простор када се роди. Нема ни расположивог простора, јер је реч о строго читаном скупу података, сама снимка не може да расте, мења или смањује. На крају, није нигде монтиран што га чини потпуно изолованим од дате хијерархије датотечног система.

Сада, уклонимо сбин директоријум у / уср / срц /

[заштићен е-поштом]: $ рм / уср / срц / сбин

Гледајући снимак видећете да је нарастао,

То се очекује јер је овде на снази механизам копирања и писања, а брисање (или модификовање) датотека довело је до тога да се већи број података повезује само са снимком, а не са скупом података који се стварно користи.

Обратите пажњу на ступац РЕФЕР у горњем излазу. Даје вам количину доступних података на скупу података, док УСЕД ступац само показује колико је простора заузето на физичком диску.

ЗФС-ов механизам Цопи-Он-Врите често даје ове контра-интуитивне резултате где би брисањем датотеке изгледало као да се сада користи више простора него раније. Међутим, прочитавши до сада, знате шта се заправо догађа!

Пре завршетка, вратимо сбин од снапсхот1. Да бисте то урадили, једноставно покрените:

[заштићен е-поштом]: / уср / срц $ зфс роллбацк зроот / уср / [емаил заштићен]

Политика снимања

Следеће питање које треба поставити је - Колико често желите да правите снимке? Иако се то може разликовати од једног предузећа до другог, узмимо пример врло динамичне базе података која се свако толико мења.

За почетак бисте почели да правите снимке сваких 6 сати или тако некако, али зато што се база података толико мења, постало би неизводљиво чувати све бројне снимке који су створени. Дакле, следећи корак био би уклањање снимака старијих од, рецимо, 48 сати.

Сада би проблем био опоравити нешто што је изгубљено пре 49 сати. Да бисте заобишли овај проблем, можете да сачувате један или два снимка из те 48-часовне историје и сачувате их недељу дана. Очистите их кад остаре.

А ако можете да наставите овим путем, могли бисте да стрпате снимке до самог настанка система, само у опадајућем редоследу учесталости. На крају, желео бих да нагласим да су ови снимци САМО ЗА ЧИТАЊЕ, што значи да ако се заражите рансомваре-ом и добијете све податке шифроване (измењене). Ови снимци би, највероватније, и даље били нетакнути.