VitaminP
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору В программе инкрементальный режим реализован по принцыпу стопки книг, только нижний полный архив не выталкивается, а сливается со следующим инкрементным и по прежнему остаётся полным. В программе устанавливается потолок (ключ -n<число>), при достижении которого начинаются слияния полного первого архива со вторым инкрементным, остальные инкрементные уменьшают свой индекс на 1, ну и в конец этой стопки пристраивается новый инкрементный архив, имеющий максимальный индекс. При таком подходе получаются обычно небольшие архивы. Но в этой схеме есть один недостаток, а именно если используется сжатие, то процесс слияния будет потреблять много времени и ресурсов системы. Ведь при слиянии нужно распаковать первый полный архив (может занимать много ГБ), затем распаковать второй инкрементный (обычно не большой), затем накатить второй на первый и результат упаковать в обновлённый полный первый архив. Как раз процесс финальной упаковки и будет самым трудоёмким. Конечно можно всего этого избежать, установив очень высокий потолок (ключ -n<число>) и при каждой архивации будут создаваться только инкрементные архивы и стопка архивов будет всё время увеличиваться, прирастая новыми. На практике не всегда бывает нужно иметь такую большую глубину архивации (точек восстановления) и здесь пришла идея двухблочных инкрементных архивов, которые решают проблему слияния архивов. В этой схеме слияний просто нет. Сам процесс можно представить так: выполняем инкрементую архивацию в одну папку, когда количество архивов дойдёт до максимального (ключ -n<число>), то переходим к созданию следущего блока в новую папку. Когда заполнится и вторая папка, то происходит ротация: первая папка удаляется, вторая становится первой, и начинается создание нового второго блока. Из моей практики: - инкрементный режим (с недостижимым потолком) использую для архивации в Облако - двублочный инкрементный для архивации по сети, на внешние HDD, флешки |