Phenquestions
Потому что, даже если вы придерживаетесь выпусков с долгосрочной поддержкой (LTS), дистрибутивы Linux часто существенно больше подвержены риску, чем компьютеры с Windows, внезапно и резко прекратить свою деятельность.
Почему во многих случаях это так??
- Совместимость оборудования, в том числе для основных компонентов, таких как графические процессоры, остается серьезной проблемой, поскольку многие поставщики все еще не поддерживают дистрибутивы Linux, оставляя на усмотрение сообщества создание обходных решений;
- Финансовая модель с открытым исходным кодом не стимулирует, а тем более не требует тщательных процессов контроля качества;
- А для тех, кто следит за новейшими выпусками, фундаментальные изменения в инструментах управления пакетами имеют неприятную привычку иногда ломать систему, открывая непоправимый ящик Пандоры с зависимостями. Их ремонт, даже когда это возможно, может включать в себя заедание кроличьих нор на несколько дней. То, что может показаться хорошим обучением для начинающего пользователя, может стать серьезным разочарованием для опытного пользователя, готового перейти на Windows.
Проблема стабильности Linux привела в ярость многих пользователей. Просмотрите множество тем о пользователях, терпящих бедствие, на AskUbuntu.com, и вы встретите множество разочарованных плакатов, которые все перепробовали и в конечном итоге решили, что единственный выход - установить с нуля.
Хотя сначала это может быть своего рода процесс обучения, побуждающий пользователей периодически переосмысливать, как они могут сделать свою систему более компактной и оптимизировать процесс восстановления, через некоторое время это становится ничем иным, как большой, отнимающей много времени неприятностью. Рано или поздно даже самые продвинутые опытные пользователи начнут жаждать стабильности.
Я использую Linux в качестве своей повседневной ОС более 10 лет и пережил изрядную долю нежелательных чистых установок. На самом деле так много, что я пообещал, что моя последняя переустановка будет последней. С тех пор я разработал следующую методологию. И это помогло моей системе Lubuntu работать так же хорошо, как и в тот день, когда я ее установил без переустановки, так как. Вот что я делаю.
Соображения: что вам нужно для резервного копирования?
Прежде чем выбрать стратегию резервного копирования, вам необходимо выяснить некоторые основы:
- Что вам нужно для резервного копирования? Вам нужно сделать резервную копию всего раздела / тома или только домашнего каталога пользователя??
- Подойдет ли для вашего варианта использования стратегия инкрементного резервного копирования? Или вам нужно делать полные резервные копии?
- Нужно ли зашифровать резервную копию??
- Насколько простым должен быть процесс восстановления??
Моя система резервного копирования основана на нескольких методологиях.
Я использую Timeshift в качестве основной системы резервного копирования, которая делает инкрементные снимки. И я храню на сайте полную резервную копию диска, исключающую каталоги, не содержащие пользовательских данных. По отношению к системному корню это:
- / dev
- / proc
- / sys
- / tmp
- /запустить
- / mnt
- /СМИ
- / потерян + найден
Наконец, я храню еще две резервные копии. Один из них - (настоящий) полный системный раздел для резервного копирования образа с использованием Clonezilla живой USB. Clonezilla упаковывает серию низкоуровневых инструментов для репликации установок. А второй - это внешняя полная резервная копия системы, которую я загружаю в AWS S3 примерно раз в год всякий раз, когда в моем распоряжении есть отличный канал передачи данных.
Параметры средств резервного копирования
В наши дни выбор инструментов, которые вы можете использовать, велик.
Это включает:
- Хорошо известные интерфейсы командной строки, такие как rsync, которые могут быть написаны по сценарию и вызываться как задание cron вручную
- Такие программы, как Déjà Dup, Duplicity, Bacula, которые предоставляют графические интерфейсы для создания и автоматизации планов резервного копирования на локальные или удаленные целевые серверы, в том числе обслуживаемые распространенными поставщиками облачных услуг
- И инструменты, которые взаимодействуют с платными облачными сервисами, такими как CrashPlan, SpiderOak One и CloudBerry. В последнюю категорию входят услуги, которые сами предоставляют дешевое облачное хранилище, поэтому предложение является полностью непрерывным.
Правило 3-2-1
Я собираюсь дать краткий обзор инструментов, которые я сейчас использую на своей основной машине.
Хотя я написал несколько сценариев Bash для загрузки важных файлов конфигурации в основное облачное хранилище, которое я использую для повседневных файлов, этот (важный) компонент моего плана резервного копирования просто создает резервную копию всей машины, включая виртуальные машины и систему. файлы, которые следует исключить или создать резервную копию отдельно в более тонких подходах.
Его основная предпосылка - соблюдение правила резервирования 3-2-1. Такой подход должен обеспечить безопасность ваших данных, включая вашу основную ОС, практически в любом сценарии сбоя.
Правило гласит, что вы должны соблюдать:
- 3 копии ваших данных. Я всегда говорю, что это немного неправильно, потому что на самом деле это означает, что вы должны сохранить свой основной источник данных и две резервные копии. Я бы просто назвал это «двумя резервными копиями»
- Эти две резервные копии должны храниться на разных носителях. Вернемся к простым терминам домашних вычислений. Вы можете написать простой сценарий rsync, который (постепенно) копирует ваш основной SSD на другой подключенный носитель - скажем, жесткий диск, подключенный к следующему порту SATA на вашей материнской плате. Но что произойдет, если ваш компьютер загорится или ваш дом ограбят? Вы останетесь без основного источника данных и без резервной копии. Вместо этого вы можете создать резервную копию своего основного диска на сетевом хранилище (NAS) или просто использовать Clonezilla для записи его на внешний жесткий диск.
- Одна из двух резервных копий должна храниться вне офиса. Внешнее резервное копирование жизненно важно, потому что в случае катастрофического стихийного бедствия, такого как, например, наводнение, весь ваш дом может быть разрушен. Менее драматично то, что серьезное событие перенапряжения может привести к сгоранию всей подключенной электроники в доме или всех тех, что находятся в определенной цепи (поэтому имеет смысл держать одну из резервных копий на месте без подключения к источнику питания - примером может быть простой внешний жесткий диск / SDD ).Технически «вне офиса» - это любое удаленное место. Таким образом, вы можете использовать Clonezilla для удаленной записи образа вашей операционной системы на рабочий компьютер или подключенный к нему диск через Интернет. В наши дни облачное хранилище достаточно дешево, чтобы по доступной цене устанавливать даже полные образы дисков. По этой причине я полностью раз в год создаю резервную копию своей системы в корзине Amazon S3. Использование AWS также дает вам значительную дополнительную избыточность.
Моя реализация резервного копирования
Мой подход к резервному копированию основан на нескольких простых правилах:
- Я хочу, чтобы все было как можно проще;
- Я хочу обеспечить себе максимальную избыточность, которую я могу разумно достичь;
- Я хочу, как минимум, следовать правилу 3-2-1
Итак, я делаю следующее.
- У меня на рабочем столе есть дополнительный диск, который используется исключительно для Timehsift точки восстановления. Поскольку я посвящаю ему целый диск, у меня есть достаточно места, чтобы поиграть с ним. Я храню ежедневные, ежемесячные и еженедельные резервные копии. Пока что Timeshift - это все, что мне нужно, чтобы откатить систему на несколько дней до момента, пока что-то, например, новый пакет, не оказало неблагоприятного воздействия на другие части системы. Даже если вы не можете пройти через GRUB, Timeshift можно использовать в качестве интерфейса командной строки с правами root для восстановления системы. Это удивительно универсальный и полезный инструмент. Это первая копия на месте.
- У меня на рабочем столе есть дополнительный диск, который используется исключительно для размещения образов Clonezilla моего основного диска. Поскольку эти изображения действительно были бы полезны для меня только в случае сбоя Timeshift, я делаю их только раз в три-шесть месяцев. Это вторая копия на месте.
- Используя Clonezilla, я создаю дополнительный жесткий диск, который храню дома вне компьютера. За исключением того, что для этого жесткого диска я использую резервную копию устройства-устройства, а не резервную копию образа устройства, как в предыдущем образе, так что было бы хорошо, если бы мой основной диск был заблокирован немедленно. Если бы мне пришлось восстанавливаться, например, с внутреннего резервного диска Clonezilla, мне нужно было бы сначала выполнить процесс восстановления. Предполагая, что другие компоненты системы находятся в хорошем рабочем состоянии после сбоя жесткого диска, теоретически мне нужно было бы только подключить этот диск к материнской плате, чтобы начать его использовать. Это третья копия на сайте.
- Наконец, примерно раз в полгода я загружаю образ своей системы, созданный с помощью Clonezilla, в AWS S3. Излишне говорить, что это долгая загрузка из нескольких частей, и ее необходимо выполнять через Интернет-соединение с хорошей ссылкой для загрузки.
В целом моя система включает три локальные копии и одну внешнюю копию моего основного рабочего стола.
Основные выводы
- Все пользователи Linux должны иметь надежные стратегии резервного копирования
- Правило резервного копирования 3-2-1 - хороший критерий для обеспечения безопасности ваших данных практически при любых обстоятельствах.
- Я использую комбинацию Timeshift и Cloudzilla для создания резервных копий, хотя на рынке есть множество других вариантов, в том числе платных. Для облачного хранилища я использую простую корзину AWS S3, хотя, опять же, есть интегрированные сервисы, которые включают как программное обеспечение, так и инструменты хранения.
