Товарищи админы! Очень надо!
Откатите пожалуйста все на 2013 год. Ну пожалуйста! Надеюсь бекапы остались у вас!
Откатите пожалуйста все на 2013 год. Ну пожалуйста! Надеюсь бекапы остались у вас!
Бэкапы часто начинают только после похожих залетов.
В бытность работы сисадмина, приходила сотрудница - записали фотки на компакт-диски, удалили исходники, а они читаться не хотят.
Причем хитро, на некоторых приводах вообще, на некоторых что-то считывалось.
Часть удалось восстановить, обращалась ли ещё к кому - хз.
Облако, локальный и нормальное внешнее сетевое хранилище (nas) спасет данные.
Последнее время задумываюсь взять второй и настроить между ними синхронизацию
Ну или привет импортозамещение?
Сегодня в большей степени технический пост про автобэкапы Huawei (AR6120 и S5735). Но я буду разбавлять текст художественными вставками.
Почему не rancid? Все, мне кажется, задают этот вопрос в любом посте про автобэкапы. Во-первых, что-то я быстрым поиском не нашла там поддержку Huawei нужных моделей, во-вторых я хочу прям классический файл бэкапа, который можно раскатать (а rancid снимает вывод консоли, что не одно и то же), в-третьих я хочу гибкий инструмент, которым я смогу позже, например, раскатать всем правило в access-list или выполнить любую команду.
Ну и вообще, я хочу понимать как оно работает, а не использовать сторонний софт, но это уже мои загоны.
Итак, нужно логиниться на Huawei, желательно, по ssh ключу (чтоб не палить пароли в скриптах), выполнять сохранение конфигурации с определенным именем, потом заливать по tftp на сервер тоже с определенным именем, анализировать что слилось, а что нет, коммитить в git и отсылать отчет на почту.
Надо сказать, что энтерпрайзные huawei умеют, как циски, при сохранении конфигурации автоматом отсылать на ftp конфиг. Теоретически, младшие модели это тоже умеют, но практически это нихрена не работает во-первых, а во-вторых оно сливает только zip архив, что просто адски неудобно (про это будет подробнее ниже).
Единственное, что я пропущу - это настройка git. Я подняла gitea чудесно по родной инструкции, справится любой. Да и система контроля версий тут не строго обязательна в принципе.
Первое - логин на Huawei по ssh ключу. И сразу это ввергло меня в поиск. То есть, в документации такая фича есть, но ключ он принимает только в HEX виде и никакие популярные команды преобразования, которые на раз гуглятся, не привели ключ в тот вид, чтобы его сожрал Huawei.
Сначала генерируем ключ на сервере (у меня хуавей принял только 1024 бита, но поскольку ssh открыт только с белого списка адресов, я сочла это приемлемым. вы же можете поэкспериментировать с битностью). На вопрос о парольной фразе просто нажмите enter.
ssh-keygen -f ~/.ssh/id_rsa -t rsa -b 1024
А теперь делаем магию. Я нашла нужную команду в самом конце комментов под заплюсованным ответом на stackoverflow. Команда из заплючованного ответа не работала и кто-то скромно написал, что не работает, но вот для моего хуавея делаю вот так и работает, тысяча плюсов в карму этому господину.
ssh-keygen -e -m pem -f ~/.ssh/id_rsa.pub | sed '1d;$d' | tr -d '\n' | base64 -d | xxd -c 24 -g 4 -u | sed -e "s/^.*: //" -e "s/.\{25\}$//g"
на выводе вы получите примерно вот такую простыню, нужно будет сохранить (не переживайте за меня, это тестовый ключ)
Дальше заводим ключ на Huawei. Ключ надо будет копировать в команды прямо так, как он вам вывелся на предыдущем этапе. На Huawei AR6120 команды следующие (если у вас белый список на логин по ssh не забудьте также разрешить ip вашего сервера логиниться):
Внимание, вот ссылка на весь код и команды текстом, я не изверг, просто пикабу не позволяет нормально вставлять код. В конце продублирую ссылку.
На коммутатор Huawei S5735 команда чуть-чуть отличается, есть по ссылке в конце.
Для обращения к устройствам из скрипта я завела БД на sqlite, но вы можете брать информацию из текстовых файлов или ещё откуда. Поле пароля в базе будет пустым, оно оставлено для устройств, которые не поддерживают логин по ключу (вдруг такие будут)
Структура базы:
Вставка происходит примерно так:
`insert into netdev (hostname,ip,login,pass,tag,model) values ( 'ufa-ar6120-2', '10.2.100.2','backuper','','huawei','AR6120');`
Теперь про скрипт. И на цисках, и на микротиках, и на D-Link прекрасно работала следующая схема:
На хуавее же логин при такой схеме происходит, в логах это видно, но никакие команды, переданные таким способом, не выполняются. Никакие манипуляции c -i -T -t не работают. Я закопалась в процессе в логи ssh, в переменные окружения и прочее. Примерно понятно, что открытый терминал не считается терминалом и это даже нормально, но никакие опции, которые туда должны впихать команды, не работают. Моего скилла победить эту конструкцию не хватило. Пришлось использовать expect.
Кстати, если кто может нормально описать почему оно не работает и как это побеждать - будет здорово. А то я как собачка - вроде частично понимаю, а нормально написать не могу.
Всего использоваться будут 5 скриптов (напомню, код текстом по ссылке в конце).
Первый скрипт разбирает базу и запускает бэкап для каждого устройства в параллель.
Сначала у меня был один скрипт expect на все устройства (команды то одинаковые), но на коммутаторах он в 20% случаев не успевал с первой командой, так как на них очень-очень долгая загрузка после логина. А на роутерах наоборот, он завершался, не успев получить вывод от tftp и завершал сессию. Пришлось расставить костыли в виде sleep и разделить на два скрипта.
Для роутеров вот, для коммутаторов по ссылке в конце.
У Huawei и cisco немного по-разному сделан текущий конфиг.
Текущий конфиг (аналог running-config) по команде save сохраняется на Huawei в vrpcfg.zip. Как уже писалось выше, при попытке сохранять это по tftp/ftp это падает всегда zip архивом и при распаковке у конфига внутри архива всегда одно и тоже имя. То есть, на такие автоматические бэкапы всё равно надо накручивать скрипт распаковки и переименования. НО! Конфиг можно сохранить в текстовом виде с любым именем .cfg и уже его сливать.
Если вам нужно добавить дату - можно добавить её в имя конфига, который будет падать по tftp (чтоб на роутере память не занимать - там всегда сохраняем с одинаковым именем). Я не добавляю дату, так как всё падает в git, там версионность поддерживается и так.
Далее идет скрипт для оценки того, что у нас накопировалось - хочется понимать, что успешно, что нет. А также коммит, пуш и отсылка отчета на почту.
Зачем каждый раз выбирать ключ ssh? Huawei сожрал только 1024 бита, а gitea хотела минимум 2048. Так что пришлось завести два и менять - один для логина, другой для коммитов.
Теперь сам анализатор логов analyse_result. Он простой как валенок, тут ваша фантазия может разгуляться. Я просто смотрю что написано success на сохранении и на копировании. Заметьте, у роутеров и коммутаторов строчки вывода разные.
Я в таких вспомогательных скриптах придерживаюсь понятного стиля написания, не гоняясь за умещением всего в одну строчку (чтоб потом вспомнить, что там вообще было), так что стиль такой не просто так)
Ну и пихаем в cron чтоб выполнялся каждый день:
Изменения в Gitea выглядят примерно вот так
Сколько времени на это ушло? Ну вот столько:
9 дней работы от 30 минут до 3х часов в день или 19 коммитов. Больше всего я боролась с логином по ключу и с удаленным выполнением команд.
Осталось раскатать это на 260 устройств :) Потом можно что угодно раскатывать сразу на все, используя эти наработки. Например, в планах составить рамочный access-list (он как бы есть, но слишком пошли различия от филиала к филиалу, хочется причесать). Ну а пока - залогиниться на каждое устройство ручками и вписать пользователя с ключом.
Занималась я этим чтобы немного размять мозги и проветриться от бумажек с отчетами, что с успехом достигнуто. Ну и для рабочей пользы.
Понятное дело, сейчас Huawei такого типа (малый офис, скажем так) не очень распространены в РФ. Уже не домашний роутер, ещё не энтерпрайз. Однако, он завозится активно, а материалов хрен да нихрена. Надеюсь, кому-то когда-то пригодится.
На старой Windows 7 не работает теневое копирование томов и всё с этим связанное. Все копипастные решения были опробованы, пока в глубинах форумов не наткнулся на то, что в системе отсутствует сверхважный файл. После попытки восстановления его по непосредственной инструкции - небольшое изменение, теперь ошибка выходит не сразу, но не более. Можно было бы последовать дальше по инструкции, но с имеющимся опытом она в большей своей части просто эльфийский (ссылка на форум с решением в конце поста).
На новом жестком диске в процессе и после установки Windows 10 экран целиком в артефактах, из-за которых текст почти не читаем. Видеокарта говорит об ошибке под кодом 43, однако все попытки установить драйвера ни к чему не привели - Windows либо делает вид, что их нет, либо сразу после их обнаружения (посредством поиска в панели управления) и перезагрузки ничего не меняет (так же не видит). CCleaner с чисткой реестра уже применялся, равно как и попытка установки через Driverhub. Вариант с "более старой версией" не прокатывает, ибо установщик Nvidia, как я понял, всегда берет последнюю версию.
Предыстория: заглючил ПК, сначала картинка, затем звук, после чего тот выключился и не смог сразу распознать жесткий диск. Сразу же был куплен новый жесткий диск (имеется опыт полной потери диска). Попытка клонирования посредством сторонних программ к результатам не привела, как и попытка клонирования посредством резервного копирования.
Старая - Windows 7 x64 Домашняя базовая
Новая - Windows 10 x64 Домашняя
Видеокарта - Nvidia GeForce GTS 450
Дополнительная информация при необходимости
Здравствуйте, IT сообщество!
Прошу поделится своим опытом по решению довольно тривиальной задачи, а именно - копирование бэкапов с основного сервера на бэкапный.
Схема такова: имеется win сервер 2012R2, который ежедневно бэкапит базы 1с и всякие другие нужные папки с диска C: на диск D:
При этом "все яйца хранятся в одной корзине", и, чтобы этого избежать, появляется бэкапный сервер с большим диском на том же 2012R2
Оба сервера соседи, находятся в датацентре, соединяются между собой...
а вот тут начинаются варианты:
- либо через роутер микротик RB2011UiAS-RM по гигабитным портам, которые в режиме свитча
- либо напрямую между собой, через вторую сетевуху основного сервера кроссовером в бэкапный
микротик особо не загружен, но ежедневный бэкап около 150 Гб
закачку должен инициировать бэкапный сервер, отсюда второй вопрос, как и чем лучше всё это реализовать? например:
- через ftp, который есть на основном
- через расшаренную папку (вот так совсем не хочется, ибо нужна максимальная защищённость бэкапного сервера от основного, чтобы не пролезли всякие зловреды)
- через что ещё можно? без шифрования передачи, нужна максимальная скорость, но так, чтобы при заражении основного чем-нибудь плохим, бэкапный выжил бы
Сколько работал сисадмином, вечно люди теряли свои документы либо жаловались, что сохранялись, но вот бы вернуться обратно и вернуть те данные, которые я "затёрла". Вот где взять предыдущую копию документа?
Ну не проблема думаю я, сейчас мы быстренько из теневых копий вытащим, а там фиг, они черте-когда сделаны, да и забыть легко, хоть засохраняйся. А ещё парк компов как обычно древний, не из-за того, что денег у фирмы нет, сами-то компы по конфигурациям хорошие, но приложения есть такие, что им только, например, Windows XP подавай, ладно бы хоть Windows 7.
И тут натыкаюсь на эту программу:
Программа мониторит изменения в папке Документы и при любом изменении файла, тут же делает его копию. Программа сохраняет все версии всех файлов (или указанных Вами) из папки Документы, таким образом Вы можете вернуться к предыдущей версии любого файла одним щелчком мыши и пересохранить его, если потребуется.
Одним кликом мыши Вы можете сделать копию папки Документы на текущую дату. Папку для версий файлов Вы можете задать самостоятельно.
Для удобства выбора, имеется возможность указать расширения файлов, какие файлы считать документами, а какие изображениями, а также можно указать копии каких файлов не делать. Кроме того, можно делать версии не только всех файлов в папке документы, а только тех, которые Вы указали в качестве документов или изображений. В любой момент Вы можете удалить любые ранее сделанные версии файлов.
В случае использования многими пользователями общей папки (указанной Вами в настройках) для хранения версий файлов папки Документы, список версий можно обновить вручную, если он не обновился автоматически.
Программа тестировалась и усовершенствовалась на операционных системах Windows XP SP3, Windows Vista, Windows 8, Windows 8.1, Windows 10, Windows 11, а также соответствующих им серверных версиях, показала себя с лучшей стороны и не вызывает нареканий.
Системные требования:
- Windows XP SP3 (домашняя редакция не поддерживается из-за .NET Framework 4.0) и выше
- Windows Server 2003 SP2 и выше
Загрузить установочный файл (размер: 0,5 МБ): setup_eclatsoftversidoc_1.1.zip
Загрузить установочный файл (включает в себя библиотеку .NET Framework 4.0, размер: 50,3 МБ) можно по ссылке: http://dl.eclatsoft.ru/files/setup_eclatsoftversidoc_1.1_dot4.zip
Отчёт VirusTotal: https://www.virustotal.com/gui/file/14054e3daeb597aa371aacffc66cbb06da574bbb111d0616cdb7a8bfdbbdc06b/detection
Ограничения данной версии: Версии любых файлов старше 7 дней автоматически удаляются, файлы в папке Документы затронуты не будут.
Я понимаю, что обращаюсь к копипасте, но тут уж надежда, что скопипастивший передаст.
АХТУНГ! БЭКАПЫ! ФАЙЛО ВОПАСНОСТЕ!
Флешка не подходит для архивного хранения! Она позволяет хранить данные будучи отключённой от питания, но это не навсегда, а только до того момента, пока заряды не поутекают. Прочитается ли флешка, год пролежавшая в тумбочке, это уже вопрос - скорее всего да, но уже без гарантий. Десять лет уже скорее всего не сохранит данные без питания никакая флешка.
Оптические диски в этом случае тоже не гарантия на все случаи жизни, там разрушается органика в защитном и отражающем слоях, через те же 10 лет он может уже не прочитаться. На коробке с болванкой могут написать "гарантию" на 25 например лет, но когда она перестанет читаться через 5, то выяснится, что для этих 25 лет надо было писать на конкретном приводе на конкретных настройках, а потом все 25 лет хранить в холодильнике, а раз не сделал этого, то и за гарантийными обязательствами обращайся к энтропии.
Ни один физический носитель в принципе не годится на роль надёжного хранилища, про которое можно забыть на десятки лет. Любая херня норовит сдохнуть тем, или иным образом. Херня бытовая при этом норовит сдохнуть молча и до обидного быстро. И от беспроблемности хранения фото в виде негативов сто лет в кожаном чемодане мы к сожалению ушли в сторону значительного увеличения геморроя.
Впрочем из всего вышесказанного не следует, что мы обречены терять свои важные данные. Просто их сохранность определяется не разовым удачным выбором носителя, а рутинными действиями по этой сохранности обеспечению.
Раз уж мы пришли к осознанию хранения данных как рутины, то очень важно ограничить объем хранимых данных, чтобы от этой рутины не надорваться. Это в целом вопрос несколько творческий, но пара рекомендаций есть.
- То, что можно найти в продаже, или на торентах хранить не надо никогда. (Точнее нет никакого резона прикладывать свои усилия к сохранности такого контента. Сразу же стирать только что скачанный фильм я не призываю, надеюсь это очевидно.)
- То, что вы не знаете что, надо не хранить, а разбирать - если вы в идеальном виде пронесёте сквозь десятилетия образ диска Цэ с вашего любимого ноута, где в глубинах каталогов есть бесценные файлики, там их потом никто не найдёт, предел срока жизни таких данных равен вашему сроку жизни, рабочий_ноут_диск-с.img 300ГБ выкинут на ваших похоронах.
- Хранить надо не программы, а данные*. На самом деле нет, но тут нюансы. В принципе программы относятся к легкоскачиваемому контенту и не требуют хранения по пункту 1. Кроме того работоспособный сетап из ОСи и прог, которым вы работаете со своими данными, попадает во вторую категорию и при попытке "сохранить всё!!!!!1111" вы только снизите шансы полезных данных на выживание. Но если в качестве единицы хранения вы для себя сформулировали фотоархив, то положить в папку с ним портейбл версию софта, в котором вы его ведёте, это практика, которая вам в будущем несколько упростит жизнь. (При условии, что вы как-то этот архив ведёте, а не просто сваливаете файлы в папки.) Может быть через тридцать лет формат например библиотеки лайтрума станет стандартом, как сейчас PDF, а может вы получите ситуацию как сейчас с видео в smk, заранее такое знать не дано.
- Сжатие дело хорошее, но не стоит возводить его в культ. Например 7zip с MFilter плагином поставят любой проц на колени, но сожмут джипеги процентов на 20, с точки зрения любого другого беспотерьного сжатия это феноменальный результат! Но с точки зрения архивного хранения за это надо гвоздь в голову вбить. Старообрядческого zip более чем достаточно. Вы не скажете себе (и мне) спасибо за этот выбор, вы просто не будете замечать тот геморрой, которого с ним избежали. Часто даже имеет смысл архивирование без сжатия - большинство современных форматов уже сжаты сами по себе внутри и зипование просто сложит их в единый, во многих случаях более удобный к хранению, файл. Сложность хранения в долгую представляет не объем файлов, а их количество. Именно количество файлов является множителем сложности хранения при плохой организации сокращения хранимого и его корректного именования и метаописания.
- Куда-то надо внести этот пункт, пусть в объёме будет. Не надо в процессе хранения контент пережимать с потерями в свеже выходящие форматы. Каждое такое пережатие будет ухудшать качество. Даже если несильно, то через несколько пережатий ухудшения накопятся. А если такую практику не пресечь сразу, то на одном пережатии вы вряд-ли остановитесь. Дёрнули когда-то видео с VHS в MPEG2, вот в нём пусть и лежит. От того, что оно станет в 4 раза меньше в H.265 ничего принципиально не изменится, если двадцать лет справлялись те пару гигов хранить, то и дальше справитесь.
- Данные, существующие на единственном носителе, в долгосрочной перспективе можно сразу считать утерянными. Это не вопрос если, это вопрос когда.
- Защитить данные вот-ваще-савсэм-ото-всего-крепко-накрепко невозможно. При попытке такое осуществить, вы либо доиграетесь до уничтожения данных, либо до дурки.
- Стоит осознать возможные сценарии утраты данных и строить защиту от них.
- Сценарии утраты данных проще себе представить в категориях - софтварные, хардварные, природные (в смысле влияние окружающей среды, environmental)
- хардварные потери данных встречаются реже, чем софтварные, но чаще чем природные, исходя из этого нужно выбирать места хранения архивов
- Арендуем стойки в трёх датацентрах тир4 в разных концах света, ставим там ленточные роботизированные библиотеки и синхронизируем через квантовый спутниковый канал
- идеального сценария не будет, его универсального не существует в природе, но попробую описать подход в общих чертах, который можно было бы по месту подогнать напильником
айн
- сетевая шара прекрасно подойдёт как первая линия обороны, может это расшаренный диск на роутере, может отдельное специализированное устройство, а может самосборный комп, по сути без разницы, файлы там прекрасно перезимуют неосторожное размахивание кнопкой делит, или переустановку винды на вашем компе (на всякий случай повторю первый тезис - данные должны не храниться на сетевой шаре в единственном экземпляре, а копироваться туда для архива)
- ещё лучше будет, если эту сетевую шару вы не будете использовать как подключаемую букву диска, а только как таргет для программы бэкапера, стойкость к софтварным причинам потери данных в таком случае резко вырастает
- если следить за тем, что сетевая шара с бэкапами не сдохла, то уже данные могут себя неплохо чувствовать в долгосроке
- сетевая шара это удобно, но требует навыка создания и использования. если навыка нет, то пойдёт и usb hdd в тумбочке. в принципе пойдёт и любой другой съемный физический носитель, но usb универсальнее, а hdd стабильнее. важный момент - его нормальное состояние это отключённое. если он постоянно подключен к компу, то он подвержен всем напастям компа и местом бэкапа не считается.
- архив на первой линии должен быть свежим, регулярно обновляемым, может по событиям документогенерации, а может например еженедельно бэкапером по расписанию
цвай
- это уже точно должно быть что-то выключенное. если на первой линии сетевой диск, то тут можно добавить хард в тумбочку, если там был хард в тумбочке, то тут можно накатать болванок
- требования к частоте обновления здесь существенно ниже, нет смысла каждый вечер свежие фотки копировать на все бэкапы, можно и лишнюю неделю (месяц) другую (другой) помариновать на первой линии, поднакопить изменения
- не про данные, а вообще: хоть я везде пишу про хранение в тумбочке, но диск с бэкапами лучше хранить в том же кожаном портфеле, что и все важные документы (паспорт, свидетельство о рождении, браке, правоустанавливающие на квартиру...), а сам портфель должен быть доступен без ныряния рыбкой в хлам чулана. кто хоть раз переживал пожар, или сопоставимый по масштабу пиздец, то не будет спрашивать зачем.
драй
- кстати хуяк и пожар/ограбление/землетрясение/наводнение/военные действия
- с бумажными документами такое не прокатит, а вот данные можно обезопасить копированием
- если у вашей мамы, или вашего сына, или вашего лучшего друга будет лежать комплект болванок, или ещё один хард с копией бэкапа, то пожалуй это максимум безопасности данных, которого можно достичь в быту
- если при этом мама/сын/друг живут в другом городе/стране/планете, то актуальность бэкапа падает, но сохранность вырастает
- раз в год-то можно и свежих данных на хранение завезти
швайн
- облачные хранилища наверное надо упомянуть
- в трёхслойной обороне они ни один слой полноценно заменить не могут
- но за неимением горничной можно поиметь и дворника
- важно понимать, что любое облако это очень временно
- до сих пор бомбит как вычитал, что родители кидали на мыло памятные моменты дочери с планом на 18летие ей отдать пароль от ящика (чтобы был понятен масштаб бедствия - почтовые сервисы, которые существовали 20 лет назад, не то, что в большинстве не дожили до сегодняшнего дня, о их существовании даже инфу сложно нагуглить, на один выживший мейлру приходятся сотни бк и ситилайнов)
Эх, тут бы пообсуждать программы резервного копирования, но я уже выдохся, чукча не писатель. Скажу только, что для домашних (хоть и обширно задротских) нужд мне хватает бесплатного Veeam.
Всем привет, на связи Уханов. В прошлом посте мы поприкалыавались на тему создания автоматических снимков файловой системы BTRFS в Debian. Тогда в конце заметки я упомянул, что Grub можно научить грузить систему прямо из снимка. Давайте сделаем это, а заодно, рассмотрим другую программу для управления снимками.
В посте про установку Debian на subvolume BTRFS я подробно рассказывал про процесс. Принцип действий будет тот-же, но subvolume должно быть только два: @ и @home. Subvolume @ мы будем использовать для корня файловой системы. Вот только нюанс в том, что установщик создаёт первый subvolume с именем @rootfs. Начнём.
Итак, дорогой друг, ты уже разметил диск, создал файловую систему и дошёл до этапа установки базовой системы. Словом, всё как в руководстве .
Итак, жми CTRL+ALT+F2 и погружайся в консоль. Осмотримся что у на по дискам:
df
Отмонтируем всё, что касается /target
umount /dev/sda1 && umount /dev/sda3
Примонтируем нашу BTRFS для работы с ней:
mount /dev/sda3 /mnt
Посмотрим что там внутри
cd /mnt ls
Как я и говорил, там один subvolume с именем @rootfs. Нам надо его переименовать, но система сделать это не даст. Ты же помнишь, что в BTRFS снимок - это тоже subvolume? Делаем финт ушами снимок subvolume, называем его @ и удаляем старый subvolume с именем @rootfs.
btrfs subvolume snapshot /mnt/@rootfs /mnt/@ btrfs subvolume delete /mnt/@rootfs
Создаём subvolume для домашних каталогов:
btrfs subvolume create @home
Проверяем сделанное:
btrfs subvolume list /mnt
Мы должны видеть два subvolume: @ и @home. Отмонтируем и монтируем корень уже куда надо:
umount /mnt mount -o rw,noatime,compress=lzo,space_cache,subvol=@ /dev/sda3 /target
Создадим каталоги:
mkdir -p /target/boot/efi mkdir -p /target/home
Монтируем оставшееся:
mount /dev/sda1 /target/boot/efi
mount -o rw,noatime,compress=lzo,space_cache,subvol=@home /dev/sda3 /target/home
Заметьте, что в отличие от предыдущей заметки я монтирую не через subvolid, а через subvol. То есть не по id, а по имени. Это важно. Там-же пишем и в fstab
nano /target/etc/fstab
Примерно так:
Жмём CTRL+ALT+F1 и продолжаем установку.
Timeshift - свободная программа, предназначенная для автоматического периодического резервного копирования и восстановления системы Linux. Она умеет создавать резервные копии через rsync или снимки BTRFS вручную или по расписанию. Установим:
sudo apt install timeshift
Пройдём несложную процедуру настройки и создадим тестовый снимок:
Для того, чтобы снимки автоматически создавались при установке, удалении и обновлении пакетов, необходимо поставить пакет timeshift-autosnap-apt. Начнём.
sudo apt install git make
git clone https://github.com/wmutschl/timeshift-autosnap-apt.git /home/$USER/timeshift-autosnap-apt
cd /home/$USER/timeshift-autosnap-apt
sudo make install
Проверим создание снимков установкой Midnight Commander:
sudo apt install mc
Видим, что снимок создан:
Для этого нам потребуется пакет grub-btrfs. Установим его.
git clone https://github.com/Antynea/grub-btrfs.git /home/$USER/grub-btrfs
cd /home/$USER/grub-btrfs
sudo make install
Теперь надо включить пункт меню загрузки:
nano /etc/default/grub-btrfs/config
Раскомментируйте пункт GRUB_BTRFS_SUBMENUNAME
Мы видим, что теперь при установке пакетов редактируется меню загрузчика GRUB:
Теперь появилось дополнительное подменю, откуда можно загрузиться в желаемый снимок.
При восстановлении снимка программа создаёт текущий снимок, чтобы восстановление можно было отменить.
У меня не заработала кнопка “Обзор” и средствами программы мне не удалось увидеть файлы в снимке. Впрочем, снимок можно примонтировать вручную.
Программа умеет делать копии и на файловой системе EXT4 при помощи rsync.
Оригинал как обычно в моём блоге.
Выспаться, провести генеральную уборку, посмотреть все новые сериалы и позаниматься спортом. Потом расстроиться, что время прошло зря. Есть альтернатива: сесть за руль и махнуть в путешествие. Как минимум, его вы всегда будете вспоминать с улыбкой. Собрали несколько нестандартных маршрутов.