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