rsync или btrfs что выбрать
Timeshift BTRFS
Проект TeeJeeTech, перевод Алексея Федорчука, оригинал
Timeshift BTRFS — это форк Timeshift для файловой системы BTRFS. Вы можете использовать это приложение только в том случае, если ваша система Linux установлена на раздел BTRFS.
BTRFS — это усовершенствованная экспериментальная файловая система со встроенной поддержкой моментальных снимков файловой системы. Поскольку моментальные снимки поддерживаются файловой системой, создание и восстановление снимков происходит очень быстро и занимает менее двух секунд. Снимки изначально не занимают места на диске и медленно «растут» по размеру, поскольку исходные системные файлы со временем меняются. Подробнее об этом читайте по следующей ссылке: Bitrot and atomic COWs: Inside «next-gen» filesystems.
Функционал
Мгновенное создание снапшотов
Создание моментального снимка BTFS выполняется очень быстро. Обычно это занимает одну или две секунды.
Снимки BTRFS создаются путем создания субтома, который делится файлами с корневым субтомом. Файлы не нужно копировать (необходимо обновлять только метаданные файловой системы), что делает процесс очень быстрым.
Нулевой исходный размер снапшотов
BTRFS — это файловая система с копированием при запись. Это означает, что при изменении существующего файла изменения записываются в новые блоки данных вместо перезаписи старых блоков данных. Таким образом, мы можем иметь несколько копий файла, которые совместно используют блоки данных друг с другом, тем самым экономя дисковое пространство.
Из-за этого моментальные снимки не занимают дополнительного места на диске при его создании. По мере того, как системные файлы изменяются в течение определенного периода времени, измененные файлы будут дублироваться файловой системой, и моментальный снимок будет постепенно «расти», чтобы занять дополнительное пространство.
Мгновенное восстановление
Снимки восстанавливаются путем переименования субтомов. Поскольку файлы не нужно копировать или удалять, восстановление моментального снимка происходит очень быстро и занимает меньше секунды.
Вы можете продолжить работу с вашей текущей системой после восстановления. Нет необходимости перезагружаться. Восстановленный моментальный снимок станет активным при следующей перезагрузке вашей системы.
Ваша текущая система будет сохранена как «моментальный снимок», который вы можете восстановить позже, чтобы отменить восстановление.
Кроме того, поскольку моментальный снимок является идеальной копией вашей системы (ничего не исключено), система, которую вы получите после восстановления, будет абсолютно такой же, как и система, с которой вы сделали моментальный снимок.
Различие между Timeshift Rsync и Timeshift Btrfs
Эти различия перечислены ниже.
Установка
В Ubuntu 12.04, 14.04 and 14.10 (а также всех последующих) устанавливается из PPA-репозитория:
В других дистрибутивах Linux необходимо скачать run-файлы с этой страницы.
Mint 19 и Timeshift: RSYNC, или простая Машина времени
Итак, последуем рекомендациям Экрана приветствия, и начнём работу со свежеустановленной системой Tara с настройки Timeshift. Как было сказано в прошлой заметке, она осуществляется по разному в зависимости от того, какая файловая система была выбрана при инсталляции в качестве корневой. Поскольку мы с Мануалом ничего не выбирали, положившись на автоматику, у нас эту роль играла Ext4. Чем и был предопределён выбор механизма создания снапшотов — RSYNC (плюс хардлинки), о чём и пойдёт речь в этой заметке.
Так что в панели выбора типа снимков на самом деле выбирать ничего не приходится — достаточно нажать кнопку Далее для продолжения работы Мастера установки:
Как в нашем случае (виртуальная машина с единственным диском и единственным разделом на нём) нет выбора и для места помещения снимков:
Хотя в общем случае при использовании механизма RSYNC для помещения снапшотов можно выбрать любое другое устройство, лишь бы файловая система на нём была исконно Linux’овая — Ext2/3/3, XFS, JFS, ReiserFS, возможно, даже Reiser4. В связи с этим возникает вопрос — а как там на счёт баб поддержки файловых систем типа F2FS или NIL2FS? Впрочем, он — чисто риторический…
Далее определяется график создания снапшотов и их количество, подлежащее сохранению. По умолчанию предлагается делать снапшоты ежедневно, и хранить их аж пять штук:
Своего мнения по данному вопросу у нас с Мануалом пока не сложилось, хотя думается, что важнее делать это при перезагрузке, А амбиции по части сохранения следует соизмерять с амуницией, то есть ресурсами по части дискового пространства: говорят, механизм RSYNC поедает его изрядно. Хотя это очень зависит от настройки исключений, во первых, и от интенсивности изменений — во вторых. Так что главное тут — помнить, что график создания скриншотов и их количество можно будет потом переопределить в любой момент.
После утверждения графика и нажатия кнопки Далее возникает главное окно Timeshift’а, в котором нет пока ничего, кроме сообщения о его активизации и указания свободного дискового пространства:
И возникает искушение заполнить пустоту окна нажав кнопку Создать (первый снапшот). Однако искушение это лучше преодолеть ради предварительного ознакомления с остальными кнопками инструментальной панели.
Назначение кнопок Восстановить и Удалить очевидно, кнопка Обзор просто вызывает (с правами администратора) файловый менеджер, в нашем случае Nemo, кнопка Мастер — это повторение пройденного пути — самых первичных настроек. А вот кнопка Настройки оказывается очень важной, ибо вызывает панель настроек с пятью кнопками (на считая закрытия): Тип, Место, Расписание, Пользователи и Фильтры.
Как нетрудно догадаться, первые три — это построение пути, пройденного с Мастером. Кнопкой же Пользователи определяется, следует ли включать в снапшоты данные, и если следует — какие именно. По умолчанию для всех пользователей (в том числе и администратора) содержимое их домашних каталогов из снапшотов исключено. Однако никто не препятствует изменить переключатели на положение Включить скрытые объекты (то есть dot-файлы) или даже на Включить всё, как это показано на скриншоте:
А затем, нажав кнопку Фильтры, установить отдельные «исключения из включений»:
С помощью кнопки Добавить в нижней панели можно задать собственные шаблоны для исключений:
Правда, нужно ли включать содержимое домашних каталогов пользователей в снапшоты — вопрос спорный. Если следовать букве цитаты, с которой мы начали, то это может повлечь потерю пользовательских данных. Однако в нашей с Мануалом ситуации этого не произойдёт: в своём домашнем каталоге мы не держим никаких данных, все они располагаются на обособленном разделе, а то и на другом носителе. Так что в
у нас нет ничего, кроме личных конфигурационных каталогов и файлов, которые требуют индивидуального обращения. И выше было показано, что таковое — вполне возможно. Правда, совсем не так, как показано в примере — он лишь иллюстрирует принцип подхода к этому делу.
Так или иначе, закончив разборки с включениями и исключениями и нажав кнопку Кратко, можно посмотреть итоговый список исключений:
И если он удовлетворяет нашим запросам, следует закрыть все вспомогательные окна и бестрепетно нажимать в главной панели кнопку Создать. За процессом создания снапшота можно наблюдать «вживе»:
Только не нужно доверять значению времени, указанному там в качестве оставшегося — оно будет всё время меняться, но в типичной инсталляции среднего дистрибутива (типа Mint’а) при создании первого снапшота меньше 10 минут не составит. По прошествии которых в ранее пустом окне появится первый снапшот, пока ещё одинокий. По правому клику мыши появляется контекстное меню доступных над ним действий:
Выбрав среди них Обзор файлов, можно убедиться, что перед нами действительно слепок исходной файловой системы. Не запрещено и Посмотреть журнал создания, но это потребует времени — парсинг более чем 250 тысяч строк потребует его немало. Возникает резонный вопрос — а почём ситчик-то (в гигабайтах дискового пространства)?
В сети можно встретить утверждение, что размер первого снапшота будет равен объёму исходной системы. Это не так. Наши упражнения проводились над Linux Mint 19 Cinnamon Edition, несколько облегчённой после установки и занимающей 6,7 ГБ (стандартная её инсталляция — 7,7 ГБ). Размер же первого снапшота составил 4,9 ГБ. Без малого два гигабайта разницы можно лишь частично объяснить исключениями, о которых говорилось выше: безусловно, какая-то компрессия в снапщоте осуществляется.
Исходя из общих соображений и из утверждения разработчиков Timeshift, можно ожидать, что механизм BTRFS окажется ещё более экономным по части дискового пространства. Но об этом — в следующем очерке нашего цикла.
1 комментарий к “Mint 19 и Timeshift: RSYNC, или простая Машина времени”
Добрый день! Спасибо. Ваш обзор очень полезен. Я установил LM 19 Tara сразу как только узнал про неё(до этого стояла LM17.3 и пора уже было обновляться) на рабочий компьютер и, не разобравшись, влепил timeshift в домашнюю папку на Рабочий Стол. Поскольку Рабочий Стол у меня настроен так, что на нём осуществляется вся деятельность целиком, то в результате папка timeshift стала изрядно весить(какое-то безумное количество гигов-так и не удалось их посчитать).
Кроме того Рабочий Стол у меня ещё и сетевая папка, в итоге компьютер стал жутко тормозить, пока я не снёс папку timeshift(она была с правами администратора) командой rm, причём удаление заняло несколько часов.
Перекрестившись я решил поузнавать что это за чудеса и ваша статья как раз к месту.
Оставьте комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Работа с программой TimeShift (Linux Mint 19.1). Создание снимков системы и восстановление
Первым делом после первой установки операционной системы по идеи необходимо было бы обновить драйвера и установить обновления. Не будем торопиться. Приятным новшеством особенно для новичков в новом дистрибутиве появилась возможность делать снимки системы (резервные копии). Данная функция появилась с появлением дистрибутива Linux Mint 19. С помощью нее можно легко восстановить систему из ранее сохраненной резервной копии, на тот случай если вдруг, что то пойдет не так.
Вот я и рекомендую сделать первую резервную копию чистой системы перед тем как устанавливать драйвера и обновления.
Разберем как это сделать.
Создание снимков
Для запуска необходимо войти в «Меню» выбрать раздел «Администрирование» и запустить утилиту «Timeshift».
При первом запуске утилиты доступен «Мастер установки».
Доступно два типа создания снимком «RSYNC» и «BTRFS». Второй тип «BTRFS» можно использовать только в том случае если Linux Mint установлен на раздел BTRFS. Поэтому выбираем первый вариант «RSYNC». Происходит оценка системы, после чего предлагается выбрать место где будут храниться снимки системы. В выбранном режиме возможно хранение снимком на другом диске, только одно условие, чтобы он имел файловую систему «ext4». На своем компьютере на одном из жестких дисков я создал специально небольшой раздел для этих целей. Выбираю его.
Хочется отметить, выбранное устройство для хранения снимком не форматируется и данные на нем не потеряются. Снимки будут сохранены в новый каталог «Timeshift» в корневом каталоге устройства.
Необходимо создать расписание создания резервных копий системы. Я выбрал создание снимков еженедельно. При необходимости снимки можно создавать вручную в любое время.
Можно указать чтобы в резервные копии системы входила домашняя папка, т. е. данные пользователя. По умолчанию домашняя папка не включена.
Мастер установки закончил свою работу. Теперь есть уверенность в том, что в случае повреждения системы или жесткого диска свои данные можно будет восстановить да и систему в целом.
После завершения работы мастера, запуститься оболочка программы. Я указал резервное копирование еженедельно, соответственно снимки будут создаваться с выбранным интервалом. Однако перед тем как начать устанавливать драйвера и обновления системы, я хочу немного подстраховаться. И для этого я вручную создам резервную копию своей операционной системы. Для этого я выбираю «Создать», утилита начинает свою работу по созданию снимка системы.
Первый снимок системы готов.
Видим, что на выбранном носителе появилась папка «Timeshift» и в ней папки со снимками системы.
Восстановление системы
Для восстановления системы достаточно выбрать снимок который необходимо восстановить и нажать кнопку «Восстановить».
Необходимо выбрать куда восстановить систему, устройства с которых был сделан снимок выбраны по умолчанию достаточно просто нажать кнопку «Далее». Произойдет разбор файла журнала, после чего будет предложено восстановить систему.
Для продолжения процедуры восстановления необходимо закрыть все приложения и сохранить данные и нажать «Далее». Компьютер автоматически перезагрузится и система будет восстановлена в соответствии со снимком системы. Хоть автор программы и не несет ответственность за любой ущерб в виде потерянной информации, но на моем примере программа отработала отлично — система была восстановлена.
Вам понравилась статья и есть желание помочь моему проекту, можете пожертвовать на дальнейшее развитие воспользовавшись формой ниже. Или достаточно просто открыть пару баннеров с рекламой, это тоже поможет мне, но и не затруднит Вас.
Создаем резервную копию Linux утилитой Timeshift
Добрый день всем, кто оказался на данном сайте. Утилита Timeshift способна создавать резервные копии вашей системы. Сама утилита проста в использовании и может работать по расписанию. В первую очередь данная утилита может понадобится тем, кто экспериментирует с настройками системы. Да и в общем, всегда приятно иметь работоспособную копию, на всякий пожарный как говорится. Утилита распространяется бесплатно и имеет открытый код. Работать Timeshift может в двух режимах, это BTRFS и RSYNC. Первый режим работает благодаря файловой системе BTRFS и создаются снимки системы с использованием встроенных функций самой BTRFS. А второй режим RSYNC создает снимки с использованием функции rsync. Стоит отметить, что утилита Timeshift предназначена прежде всего, для создания важных системных файлов и настроек. То есть, Пользовательские данные не архивируются.
Установка Timeshift
Установить утилиту Timeshift можно использую из репозитория, либо, скачав deb пакет. Мы рассмотрим оба варианта. К сожалению, имеется только ppa репозиторий, что означат что его можно подключить только в Ubuntu подобных дистрибутивах. В остальных дистрибутивах данная утилита вероятней всего присутствует в родных репозиториях. Либо, можно скачать deb файл и установить из него. И так, давайте подключим его, переходим в терминал:
Для Ubuntu
Для Debian
В Debian утилита timeshift имеется в репозиториях, для ее установки достаточно выполнить команды:
Либо, можно скачать deb пакет и установить его, например при помощи утилиты gdebi, о которой писалось в одной из статей. Для скачивания deb пакета перейдите по этой ссылке.
Для Fedora
В дистрибутиве Fedora, так же достаточно установить timeshift из родного репозитория, для этого выполняем команду:
Для Arch
В дистрибутиве Arch и его ответвлений, например в Manjaro, данная утилита имеется в официальном репозитории. Для установки в той же Manjaro вводим команду:
Настройка Timeshift
После того как вы установили утилиту timeshift, ее нужно настроить. Для этого запускаем и при первом запуске нам нужно выбрать один из вариантов, это либо RSYNC или BTRFS. Я выбирают RSYNC, так как он более универсальный:
После чего нажимаем кнопку далее. Затем после не продолжительного сканирования утилиты выдаст вам окно с вашей установленной системой:
На данном этапе вы можете выбрать место, где будут хранится ваши архивные копии системы. Если у вас есть например разделы, или еще установленные жесткие диски, то они отобразятся в этом окне:
Нажив кнопку далее, можно будет настроить расписания создания резервных копий вашей системы. Лично я устанавливаю примерно следующие настройки, их вы можете увидеть на скриншоте:
Следующим шагом нужно будет настроить разделы, которые будут архивироваться. Для этого нажимаем кнопку далее и выбераем нужные нам разделы, после чего нажимаем “далее”, а затем “Готово”:
А в данном окне будут показаны снимки, которые уже имеются и которые вы сможете восстановить. Для критического восстановления вы можете загрузится из Live режима, запустить timeshift и следуя инструкциям выбрав образ, восстановить его. Для немедленного создания снимка достаточно нажать кнопку “Создать” расположенную в левой верхней части окна.
Моя рекомендация по работе с этой утилитой создать отдельное место для хранения снимков вашей системы. Например, купить хотя бы ту же самую флэшку и настроить утилиту timeshift на создания снимков на флэшку. Либо же использовать отдельный раздел или жесткий диск. Но не как не в корневом разделе. Для чего это надо? Например в том случае если у вас появятся битые сектора на жестком диску, что бы они не затронули архивные копии вашей системы. Это лишь один из вариантов.
А на этом сегодня все. Надеюсь данная статья будет вам полезна.
С уважением Cyber-X
Опыт использования BTRFS
Я уже пару-тройку лет не использую федору, но тут в новостях проскочило, что теперь там BTRFS по-умолчанию идёт. Вопрос: есть ли смысл переезжать с ext4 полностью или частично (/ или /home)?
Я прикупил новые ssd для своего ноутбука, планирую полностью реорганизовать систему (arch, переустановка + переразбиение и перенос разделов).
На SSD я бы не ставил. Лучше F2FS. А так ФС как ФС. Со своими фичами, со своими косяками.
Не пойми меня неправильно, меня вполне устраивает ext4, работает и ладно, но обычно если в федоре что-то появляется, то оно уходит в мэйнстрим. Вот я и пытаюсь выяснить, что же там такого, что она теперь по-умолчанию идёт.
F2FS же изначально под SSD и создавалась.
Хмм, звучит любопытно, мне тут просто недавно советовали btrfs чтобы место сохранить в корне, но кроме этого никаких преимуществ не было озвучено.
Еще несколько лет назад оно ломалось от каждого чиха, от возраста, от потери питания, от 100%-заполнения, и эпично просирало данные. Короче, не рекомендую. ext4 наше все.
оно ломалось от каждого чиха
Типичный Fedora user experience.
Использую несколько лет везде, никаких проблем. Не пользуюсь RAID и сжатием. Никаких проблем с SSD нет.
Типичный Fedora user experience.
Вообще да, хоть я и не на федоре использовал
Ну я на своем много лет компелял генту, ничего с SSD не случилось. С самим BTRFS конечно случилось.
Поддерживаю. Бтрфс хороша до первой проблемы. Потом здравствуй зверек и пока-пока данные.
Лучше перебдеть, чем недобдеть.
Преимуществ у Btrfs много, но если выбирать одно, то это умение не портить данные. У всяких ext4, XFS и прочих поделок из девяностых его нет — в любом файле однажды может оказаться мусор.
«Преимуществ» у Btrfs много, но если выбирать одно, то это умение портить данные. У всяких ext4, XFS и прочих поделок из девяностых его нет, а вместо btrfs рано или поздно на диске может оказаться мусор.
Починил, не благодари.
Ну да, данные не портит, умирает сама.
Но тут пишут, что ситуация как раз противоположная.
Тут много упоротых, не обращайте внимание.
Ресурс у ssd такой, что разницы между различными ФС ты в жизни не заметишь.
Ты серьёзно веришь всяким гуманитариям? Найди источники получше, если самому лень разбираться. Просто пример: Facebook использует Btrfs в продакшене уже несколько лет. Только у лоровских чудаков она внезапно ломается, да ещё и данные портит 🤷🏻♀️
У меня не умирала, но всё же это гораздо лучше, чем silent corruption, о котором ты узнаешь уже когда битый файл будет во всех резервных копиях.
Не стоит. Достаточно почитать реддит или еще какой ресурс, где обсуждаются потери данных. Тоже самое касается и федоры. Не стоит потраченного времени.
Вывод: не стоит использовать btrfs, если программы часто записывают небольшое количество данных (несколько килобайт), иначе это обернется мегабайтами записанных данных.
Так на них же не написано, как узнать.
Вот тебе раз, а другой анонимус изображает Хрущёва: стучит ботинком и говорит, что всё совсем иначе.
Федора не так уж и плоха, но с годами приелась, оказалось, что arch лучше во многих аспектах.
Что за «имеет ли смысл», тебя ext4 чем-то не устраивает?
Ресурса много не бывает. У меня один из HDD уже 14 лет пашет и сыпаться пока не планирует. Вот пусть и SSD столько протянет.
Но они же обе поддерживают сжатие.
На данный момент вопросов нет, если не считать неудавшейся попытки переразметить диск, которая попортила кучу данных. Но времена меняются, я с ext4 уже добрых 12 лет, может появилось что-то новое, более надёжное и практичное.
У btrfs есть другие фичи. Если они нужны, лучше использовать её. Если не нужны — ну её нафик.
Томущто Reddit — это классическая echo chamber. Там каждый читает то, что ему интересно, и таким образом подтверждает свои убеждения.
А как тогда осуществлять выбор, если не ориентироваться на опыт других людей?
Надёжнее с точки зрения самой ФС ничего не появилось. Если бы в ext4 был контроль целостности данных — цены бы ей не было. Но это вряд ли возможно без ломания всего и превращения в ext5, но ext5 это Btrfs, и никто не спешит представить более внятную альтернативу, увы.
Но ты же сам про сжатие упомянул.
Формировать свой опыт. Вот у тебя сейчас Facebook и Synology против анонов с реддита. Кому верить? Надо пробовать самому!
Ресурса много не бывает. У меня один из HDD уже 14 лет пашет и сыпаться пока не планирует. Вот пусть и SSD столько протянет.
Судя по износу, мой протянет минимум 20 лет. Скорее всего, быстрее контроллер сдохнет или оно тупо морально устареет.
ОК, тут много противоречивых мнений, так что я добавлю уточняющий комментарий: мне от ФС нужно только несколько фич, надёжность, возможность делать бэкапы без головной боли (сейчас у меня просто руками всё на hdd в той же машине зеркалится) и возможность легким движением руки изменять размер разделов (сейчас LVM + ext4). Компрессия хорошая штука, но она не очень критична.
Не используй F2FS на десктопе, особенно на федоре! Дело в том, что у нее до сих пор нет стабильного формата, он периодически меняется и ты рискуешь получить сломанную фс даже при минорном обновлении ядра. Эта фс подходит только для мобильных телефонов, где ядро практически не обновляется, а если обновляется, то только под строгим контролем вендора.
Плюс снапшоты, плюс встроенный RAID с контролем целостности, минус головная боль с переразметкой.
Есть и проблемы: btrfs очень чувствительна к глючному железу, теряющему записи при потере питания. Если у тебя такое — btrfs имеет все шансы развалиться.
btrfs очень чувствительна к глючному железу, теряющему записи при потере питания
С каких это пор потери данных при потере питания вменяются в вину железу? Насколько я знаю, с этм всегда должна была справляться ФС.
Общее правило, ИМХО, если нет явных причин использовать что-то отличное от самого кондового и стандартного варианта (в данном случае ext4) — не надо использовать что-то отличное от самого кондового и стандартного варианта.
P.S. использую btrfs ради субвольюмов, немного для бесплатного копирования и снапшотов. Брат жив
точно не про BTRFS
возможность делать бэкапы без головной боли
снапшоты BTRFS помогают только как бекап против повреждения данных пользователем/софтом. например против неудачных обнвлений системы, после которой она перестала грузиться. если повредится сама ФС или носитель, на котором она находится, то снапшоты погибнут вместе с самой ФС
возможность легким движением руки изменять размер разделов
если это намёк на subvolume’ы, то они не разделы, а просто директории с некоторыми дополнительными фичами. все subvolume’ы совместно используют единое пространство раздела на котором лежит сама ФС
Давно пользуясь btrfs под корень, ессно на ssd. Подводные только в быстром забивании места из-за гигантских апдейтов (в тамбле полтора гига на апдейт обычное дело), из-за чего стандартные механизмы очистки иногда не поспевают тереть старые снапшоты и приходится делать это руками после no space left on device.
На обычном дистре, не роллинге, все будет ок.
Есть железо, которое подтверждает завершение команды записи до её реального завершения. Вот с ним и проблемы.
А ты не обратил внимание на мой маленький эксперимент для проверки сказанного?
Конкретно, ту часть, где ext4 тоже оказалась в комплекте с драконовским write amplification?
По факту, с учётом затрат на CoW, относительная разница выглядит адекватно.
Абсолютные цифры хреновые и там и там.
Недавно был в такой же ситуации и решил отказаться от нее. В конце концов от ФС нужна прежде всего надежность. Будет время, когда ее допилят, тогда и будем использовать – зачем бежать впереди паровоза?
В конце концов от ФС нужна прежде всего надежность.
Зачем нужна надёжность без целостности данных? В чём ценность файловой системы как таковой?
Есть железо, которое подтверждает завершение команды записи до её реального завершения. Вот с ним и проблемы.
Чет я не понял. То есть sync вернул ок, а данные не записаны? И где то железо было куплено?