Бекап за розкладом windows server 12. Розбираємося з утилітами для бекапу баз даних. Налаштування системи архівації windows server

Сервери баз даних - одні з ключових у будь-якій організації. Саме вони зберігають інформацію та надають видачу на запит, і вкрай важливо зберегти БД у будь-якій ситуації. Базове постачання зазвичай включає потрібні утиліти, але адміну, який не стикався до цього з БД, доведеться деякий час розбиратися з особливостями роботи, щоб забезпечити автоматизацію.

Види бекапів баз даних

Спочатку розберемося з тим, які взагалі бувають бекапи. Сервер баз даних не є звичайним десктопним додатком, і щоб забезпечити виконання всіх властивостей ACID (Atomic, Consistency, Isolated, Durable), використовується ряд технологій, а тому створення та відновлення БД з архіву має свої особливості. Існують три різні підходи до резервного копіювання даних, кожен з яких має свої плюси та мінуси.

При логічному, або SQL, бекапі (pg_dump, mysqldump, SQLCMD) створюється миттєвий знімок вмісту бази з урахуванням транзакційної цілісності та зберігається у вигляді файлу з SQL-командами (можна вибрати всю базу або окремі таблиці), за допомогою якого можна відтворити базу даних на іншому сервері. На це потрібен час (особливо для великих баз) для збереження та відновлення, тому дуже часто цю операцію виконувати не можна і її роблять під час мінімального навантаження (наприклад, уночі). При відновленні адміністратору необхідно буде виконати кілька команд, щоб підготувати все необхідне (створити порожню базу даних, облікові записи та інше).

Фізичний бекап (рівня файлової системи) – копіювання файлів, які СУБД використовує для зберігання даних у базі даних. Але при простому копіюванніігноруються блокування та транзакції, які, швидше за все, будуть неправильно збережені та порушені. При спробі приєднати цей файл він буде у неузгодженому стані та призведе до помилок. Щоб отримати актуальний бекап, базу даних потрібно зупинити (можна зменшити час простою, використавши двічі rsync - спочатку на працюючій, потім на зупиненій). Недолік цього методу очевидний – не можна відновити певні дані, лише всю базу даних. При старті бази даних, відновленої з архіву файлової системи, потрібно буде провести перевірку на цілісність. Тут застосовуються різні допоміжні технології. Наприклад, у PostgreSQL логи попереджувальної журналізації WAL (Write Ahead Logs) та спеціальна функція (Point in Time Recovery – PITR), що дозволяє повернутися до певного стану бази. За допомогою їх легко реалізується третій сценарій, коли бекап рівня файлової системи об'єднується з резервною копією WAL-файлів. Спочатку відновлюємо файли резервної копії файлової системи, а потім за допомогою WAL база наводиться актуальним станом. Це трохи складніший підхід для адміністрування, зате немає проблем із цілісністю БД та відновленням баз до певного часу.

Логічний бекап використовується в тих випадках, коли необхідно одноразово зробити повну копію бази або в повсякденній експлуатації для створення копії не потрібно багато часу або місця. Коли вивантаження баз займає багато часу, слід звернути увагу до фізичне архівування.

Barman

Ліцензія: GNU GPL

Підтримувані СУБД: PostgreSQL

PostgreSQL підтримує можливості фізичного та логічного бекапу, додаючи до них ще один рівень WAL (див. врізання), який можна назвати безперервним копіюванням. Але керувати за допомогою штатних інструментів кількома серверами не дуже зручно навіть адміну зі стажем, а у разі збою рахунок йде на секунди.

Barman (backup and recovery manager) – внутрішня розробка компанії 2ndQuadrant, що надає послуги на базі PostgreSQL. Призначений для фізичного бекапу PostgreSQL (логічний не підтримує), архівування WAL та швидкого відновлення після збоїв. Підтримуються віддалений бекап та відновлення кількох серверів, функції point-in-time-recovery (PITR), керування WAL. Для копіювання та подачі команд на віддалений вузол використовується SSH, синхронізація та бекап за допомогою rsync дозволяє скоротити трафік. Також Barman інтегрується зі стандартними утилітами bzip2, gzip, tar та подібними. В принципі, можна використовувати будь-яку програму стиснення та архівування, інтеграція не триватиме багато часу. Реалізовано різні сервісні та діагностичні функції, що дозволяють контролювати стан сервісів та регулювати смугу пропускання. Підтримуються Pre/Post-скрипти.

Barman написаний на Python, управління політиками резервного копіювання здійснюється за допомогою зрозумілого INI-файлу barman.conf, який може знаходитись у /etc або домашньому каталозі користувача. У поставці йде готовий шаблон із докладними коментарями усередині. Працює лише на *nix-системах. Для встановлення в RHEL, CentOS та Scientific Linux слід підключити EPEL – репозиторій, у якому містяться додаткові пакети. У розпорядженні користувачів Debian/Ubuntu офіційний репозиторій:

$ sudo apt-get install barman

У репозиторії не завжди остання версія, для її встановлення доведеться звернутися до вихідним текстам. Залежно небагато, і розібратися в процесі нескладно.

Sypex Dumper

Ліцензія: BSD

Підтримувані СУБД: MySQL

Разом з MySQL поставляються утиліти mysqldump, mysqlhotcopy, що дозволяють легко створити дамп бази даних, вони добре документовані, і в інтернеті можна знайти велику кількість готових прикладів та фронтендів. Останні дозволяють новачкові швидко розпочати роботу. Sypex Dumper є PHP-скриптом, що дозволяє легко створити і відновити копію бази даних MySQL. Створювався для роботи з великими базами даних, працює дуже швидко, зрозумілий та зручний у використанні. Вміє працювати з об'єктами MySQL - уявленнями, процедурами, функціями, тригерами та подіями.

Ще один плюс, на відміну від інших інструментів, при експорті перекодування в UTF-8, - в Dumper експорт виробляється в рідному кодуванні. Результуючий файл займає менше місця, а процес відбувається швидше. В одному дампі можуть бути об'єкти з різними кодуваннями. Причому легко імпорт/експорт зробити кілька етапів, зупиняючи процес під час навантаження. При поновленні процедура розпочнеться з місця зупинки. При відновленні підтримується чотири варіанти:

  • CREATE + INSERT - стандартний режимвідновлення;
  • TRUNCATE + INSERT - менше часу створення таблиць;
  • REPLACE – відновлюємо в робочій базі старі дані, не затираючи нові;
  • INSERT IGNORE - додаємо в базу віддалені або нові дані, не чіпаючи наявні.

Підтримується стиснення копії (gzip або bzip2), видалення старих бекапів, реалізовано перегляд вмісту дамп-файлу, відновлення тільки структури таблиць. Є й сервісні функції з управління БД (створення, видалення, перевірка, відновлення БД, оптимізація, очищення таблиць, робота з індексами та інше), і навіть файл-менеджер, що дозволяє копіювати файли на сервер.


Управління здійснюється за допомогою веб-браузера, інтерфейс з використанням AJAX локалізований з коробки і створює враження роботи з настільним додатком. Також можна запускати завдання з консолі та за розкладом (через cron).

Для роботи Dumper знадобиться класичний L|WAMP-сервер, звичайна установка для всіх додатків, написаних на PHP (копіюємо файли і встановлюємо права), і не буде складною навіть для новачка. Проект надає детальну документацію та відеоуроки, що демонструють роботу із Sypex Dumper.

Є дві редакції: Sypex Dumper (безкоштовно) та Pro (10 доларів). Друга має більше можливостей, всі відмінності наведено на сайті.

SQL Backup And FTP

Ліцензія:

Підтримувані СУБД: MS SQL Server

MS SQL Server - одне з найпопулярніших рішень, а тому зустрічається досить часто. Завдання резервного копіювання створюється за допомогою середовища SQL Server Management Studio, власне Transact-SQL і командлетів модуля SQL PowerShell (Backup-SqlDatabase). На сайті MS можна знайти величезну кількість документації, яка дозволяє розібратися з процесом. Документація хоч і повна, але дуже специфічна, а інформація в Інтернеті часто суперечить одна одній. Новачку дійсно спочатку потрібно потренуватися, «набивши руку», тому, навіть незважаючи на все сказане, стороннім розробникам є де розвернутися. До того ж безкоштовна версія SQL Server Express не може похвалитися вбудованим інструментом для резервного копіювання. Для ранніх версій MS SQL (до 2008) можна знайти безкоштовні утиліти, наприклад SQL Server backup , але в більшості подібні проекти вже комерціалізувалися, хоча пропонують всю функціональність часто за символічну суму.


Наприклад, розробка SQL Backup And FTP та One-Click SQL Restore відповідає принципу «налаштував та забув». Маючи дуже простий і зрозумілий інтерфейс, вони дозволяють створювати копії баз даних MS SQL Server (включаючи Express) і Azure, зберігати зашифровані та стислі файли на FTP та хмарних сервісах (Dropbox, Box, Google Drive, MS SkyDrive або Amazon S3), результат можна відразу переглянути. Можливий запуск процесу як вручну, так і за розкладом, відправка повідомлення про результат завдання по email, запуск скриптів.

Підтримуються всі варіанти бекапу: повний, диференціальний, журнал транзакцій, копіювання папки з файлами та багато іншого. Старі резервні копії автоматично видаляються. Для підключення до віртуального вузла використовується SQL Management Studio, хоча тут можуть бути нюанси і це буде працювати не у всіх конфігураціях. Для завантаження пропонується п'ять версій - від безкоштовної Freeдо навороченої Prof Lifetime (на момент написання цих рядків коштувала лише 149 доларів). Функціонала Free цілком достатньо для невеликих мереж, в яких встановлено один-два SQL-сервери, всі основні функції активні. Обмежено кількість резервних БД, можливість надсилання файлів на Google Drive та SkyDrive та шифрування файлів. Інтерфейс хоч і не локалізований, але дуже простий і зрозумілий навіть новачкові. Потрібно лише підключитися до SQL-серверу, після чого буде виведено список баз даних, слід зазначити потрібні, налаштувати доступ до віддалених ресурсів та вказати час виконання завдання. І все це в одному вікні.

Але є одне але". Сама програма не призначена для відновлення архівів. Для цього пропонується окрема безкоштовна утиліта One-Click SQL Restore, яка розуміє формат, створений командою BACKUP DATABASE. Адміну необхідно лише вказати архів та сервер, на який відновити дані, та натиснути одну кнопку. Але в складніших сценаріях доведеться використовувати RESTORE.


Особливості бекапу MS SQL Server

Створення резервної копії та відновлення СУБД має свої відмінності, які потрібно враховувати, особливо їх багато у разі перенесення архіву на інший сервер. Наприклад розберемо деякі нюанси MS SQL Server. Для архівування за допомогою Transact-SQL слід використовувати команду BACKUP DATABASE (є і різницева DIFFERENTIAL) та журнал транзакцій BACKUP LOG.

Якщо резервна копія розгортається на іншому сервері, потрібно переконатися, що присутні ті ж логічні диски. Як варіант – можна вручну прописати правильні шляхидля файлів бази даних, використовуючи опцію WITH MOVE команди RESTORE DATABASE.

Проста ситуація - бекап та перенесення баз на інші версії SQL Server. Ця операція підтримується, але в разі SQL Server буде працювати, якщо версія сервера, на якій розгортається копія, така ж чи новіша, ніж та, на якій вона створювалася. Причому є обмеження: новіша не більше ніж на дві версії. Після відновлення БД перебуватиме у режимі сумісності з тією версією, з якою здійснювався перехід, тобто нові функції недоступні. Це легко виправити, змінивши COMPATIBILITY_LEVEL. Це можна зробити за допомогою GUI або SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Визначити, на якій версії було створено копію, можна, переглянувши заголовок файлу архіву. Щоб не експериментувати, під час переходу на нову версію SQL Server слід запустити безкоштовну утиліту Microsoft Upgrade Advisor.

Iperius

Ліцензія:комерційна, є версія Free

Підтримувані СУБД: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL та MS SQL Server

Коли доводиться керувати кількома типами СУБД, без комбайнів не обійтись. Вибір великий. Наприклад, Iperius - легка, дуже проста у використанні та одночасно потужна програма для резервного копіювання файлів, що має функцію гарячого резервування баз даних без переривання в роботі або блокування. Забезпечує повний або інкрементальний бекап. Може створювати повні образи дисків для автоматичної переустановки системи. Підтримує резервне копіювання на NAS, USB-пристрої, стримери, FTP/FTPS, Google Drive, Dropbox і SkyDrive. Підтримує стиск zipбез обмеження у розмірі файлів та AES256-шифрування, запуск зовнішніх скриптів та програм. Включає функціональний планувальник завдань, можливо паралельне або послідовне виконання декількох завдань, результат відправляється на email. Підтримуються численні фільтри, змінні для персоналізації шляхів та налаштувань.

Можливість закачування FTP дозволяє легко оновлювати інформацію на декількох веб-сайтах. Відкриті файли резервуються за допомогою технології VSS ( тіньового копіюваннятомів), що дозволяє виробляти гарячий бекап як файлів СУБД, а й інших додатків. Для Oracle також використовується засіб організації резервного копіювання та відновлення даних RMAN (Recovery Manager). Щоб не перевантажувати канал, можна налаштувати смугу пропускання. Керування резервуванням та відновленням здійснюється за допомогою локальної та веб-консолі. Всі функції на увазі, тому для налаштування завдання потрібно лише розуміння процесу, документацію заглядати навіть не доведеться. Просто слідуємо підказкам майстра. Також можна відзначити менеджер облікових записів, що дуже зручно за великої кількості систем.

Базові функції пропонуються безкоштовно, але можливість резервування БД закладена лише у версіях Advanced DB та Full. Підтримується інсталяція від XP до Windows Server 2012.

Handy Backup

Ліцензія:комерційна

Підтримувані СУБД: Oracle, MySQL, IBM DB2 (7-9.5) та MS SQL Server

Одна з найпотужніших систем управління реляційними базами даних - IBM DB2, що має унікальні функції масштабування та підтримує безліч платформ. Поставляється у кількох редакціях, які побудовані на одній базі та відрізняються функціонально. Архітектура баз даних DB2 дозволяє керувати практично всіма типами даних: документами, XML, медіафайлами тощо. Особливо популярна безкоштовна DB2 Express-C. Бекап дуже простий:

Db2 backup db sample

Або снапшот, який використовує функцію Advanced Copy Services (ACS):

Db2 backup db sample use snapshot

Але слід пам'ятати, що у разі знімків ми не можемо відновлювати окремі таблиці (db2 recover db). Є і можливості з автоматичного бекапу, і багато іншого. Продукти добре документовані, хоча у російськомовному інтернеті керівництва зустрічаються рідко. Також далеко не у всіх спеціальних рішеннях можна знайти підтримку DB2.

Наприклад, Handy Backup дозволяє виконувати бекап декількох типів серверів баз даних та зберігати файли практично на будь-який носій ( жорсткий диск, CD/DVD, хмарне та мережеве сховище, FTP/S, WebDAV та інші). Можливий бекап баз даних через ODBC (тільки таблиці). Це одне з небагатьох рішень, що підтримують DB2, і має логотип «Ready for IBM DB2 Data Server Software». Вся процедура виконується за допомогою звичайного майстра, в якому необхідно вибрати потрібний пункт і сформувати завдання. Сам процес налаштування настільки простий, що зможе розібратися і новачок. Можна створити кілька завдань, які запускатимуться за розкладом. Результат фіксується в журналі та відправляється по email. Під час роботи завдання зупинення сервісу не потрібне. Архів автоматично стискається та шифрується, що гарантує його безпеку.

Роботу з DB2 підтримують дві версії Handy Backup – Office Expert (локальний) та Server Network (мережевий). Працює на комп'ютерах під керуванням Win8/7/Vista/XP або 2012/2008/2003. Сам процес розгортання нескладний будь-якого адміна.

Існує безліч способів виконати резервне копіювання окремої інформації або цілих серверів. Я хочу розповісти про найпростіший спосіб повного бекапу сервера та перенесення його на інше залізо, якщо буде така необхідність. Робиться все це дуже просто, без зайвих рухів тіла за допомогою безкоштовного Veeam Agent for Linux FREE.

Раніше я вже не раз розглядав питання резервного копіювання даних або цілих серверів linux. Саме у цих статтях:

Забекапити відразу весь сервер можна, наприклад, за допомогою Duplicity. Але відновити його на іншому залозі буде не так просто. Крім даних потрібно буде, як мінімум, подбати про розмітку диска, встановлення завантажувача. На це необхідно витратити деякі зусилля і трохи розумітися на темі initramfs і grub. Сам я не дуже розуміюся на нюансах роботи цих інструментів і дуже не люблю з ними возитися.

Якийсь час тому з'явився чудовий безкоштовний продукт для бекапу всього сервера. Мова йдепро Veeam Agent for Linux FREE. З його допомогою можна зробити повний backup сервера, покласти його кудись по smbабо nfsпотім завантажитися з live cd і відновити з бекапу на іншому залозі.

Відразу розповім про деякі нюанси роботи безкоштовної версії, з якими зіткнувся у процесі експлуатації чудового продукту від Veeam.

  1. Бекап можна зробити або всього сервера відразу, або окремого диска, або окремих папокта файлів. При виборі бекапу всього диска чи сервера, не можна встановити винятки для окремих папок або файлів. Це дуже незручно, але на жаль і ах, такий функціонал. Винятки можна зробити лише якщо ви робите бекап на рівні папок.
  2. Бекап можна покласти локально на сусідній розділ, якщо робите резервну копію розділу, локально до папки — якщо робите бекап файлів та папок. Якщо бекапіте всю систему повністю, то віддалено по smb і nfs. На жаль, ftp або sftp програма не працює.

Як сховище для архівів може бути репозиторій Veeam Backup & Replication. Але я не розглядаю цей варіант, тому що в даному випадку використовую лише безкоштовне рішення.

Мені дуже хотілося налаштувати резервну копію всього сервера на Яндекс.Диск, але, на жаль, це не вийшло через технічні обмеження. Яндекс.Диск підключається до системи через webdav. Для того, щоб зробити резервну копію всієї системи, потрібно бекапит або всю систему відразу, або образ диска. Якщо у вас невеликий веб-сервер, то швидше за все на ньому тільки один розділ. У цьому розділі зберігається кеш, який використовує webdav для передачі файлів. Без кешу він не вміє працювати.

Думаю ви вже зрозуміли, в чому проблема зробити повний backup сервер за допомогою Veeam Agent for Linux на Яндекс.Диск по webdav. Ви не зможете додати у виключення папку з кешем від webdav. У результаті, під час бекапу за допомогою veeam зростатиме папка з кешем webdav, яка, у свою чергу, буде бекапитися. Зрештою, вільне місце на диску закінчиться, бекап перерветься.

Я докладно описав ситуацію з Яндекс.Диском, тому що простір на ньому не дорогий. Я часто використовую його в повсякденному житті, налаштовую бекапи, зберігаю дані і т.д. Загалом, мені він подобається з низки причин. Для того, щоб бекапит весь сервер повністю, вам доведеться знайти місце для архівних копій з доступом по smbабо nfs. Таких пропозицій не надто багато на ринку. Практично нема з чого вибирати, я спеціально шукав.

Зупинився на цьому варіанті — . Після оплати, вам дають адресу сервера, логін та пароль. Ви можете відразу підключатися по smb до сховища. Можна прямо в windows через два зворотних слєша зайти або підмонтувати сховище до linux серверу.

Щоб отримати доступ до розділу із завантаженнями, доведеться зареєструватися. Вибираєте тип системи та завантажуєте ріпу.

Копіюємо файл з репозиторієм на сервер та встановлюємо його. На момент написання статті файл можна було завантажити за прямим посиланням.

# cd /root # wget https://download2.veeam.com/veeam-release-el7-1.0-1.x86_64.rpm # rpm -Uhv veeam-release-el7-1.0-1.x86_64.rpm

Оновлюємо репозиторії та встановлюємо veeam.

# yum update # yum install veeam

Все, Veeam Agent for Linux встановлений та готовий до роботи.

Налаштування повного бекапу сервера

Зробити бекап за допомогою Veeam Agent for Linux дуже просто. Варіантів налаштувань не так багато, можете самі все перевірити та подивитися. Я для прикладу розгляну варіант із створенням повного бекапу всієї системи та перенесення її на інше залізо. Створюємо завдання резервного копіювання сервера на наше сховище по smb.

Нам відразу пропонують вказати файл з ліцензією. Так як у нас ліцензії немає, то відмовляємось. Нас зустрічає головне вікно програми.

Натискаємо C (configure)для налаштування завдання на backup. Задаємо будь-яке ім'я завдання, потім вказуємо, що робитимемо повний бекап сервера.

Як приймач для архіву системи, вказуємо Shared Folder.

У пункті Restore Pointsвказується глибина архіву. Це число копій, які зберігатимуться на сервері. Якщо робити бекап щодня і вказати число 14, зберігатимуться резервні копії системи за останні 14 днів. Якщо робитимете через день, то за 28 днів і т.д.

Можна створювати кілька завдань із різною глибиною архіву. Наприклад, кожен день із глибиною 7 копій, раз на тиждень із глибиною 4, і раз на місяць із глибиною в 12. Таким чином у вас завжди будуть останні 7 бекапів системи на цьому тижні. Потім по одному бекапу на тиждень за останній місяць і 12 бекапів по місяцях протягом останнього року.

Якщо отримаєте помилку:

Сучасна система не підтримує CIFS. Please install cifs client package.

Встановіть пакет cifs. У CentOS ось так:

# yum install cifs-utils

І так у Debian/Ubuntu:

# apt install cifs-utils

Запускайте наново veeam і продовжуйте. Після налаштування Destination, пропонується вказати скрипти для виконання перед та після бекапу. Нам зараз це не треба. Далі налаштовуємо розклад та запускаємо завдання на архівацію в кінці налаштування.

Запустилася архівація. Можна стежити за її прогресом.

Після завершення архівації системи можна перевірити вміст мережевого сховища, зайшовши на нього прямо з вінди.

На цьому налаштування повного бекапу сервера ми завершили. Резервна копія системи лежить у надійному місці. Спробуємо тепер із неї відновитися.

Перенесення чи відновлення linux сервера

Уявимо тепер ситуацію, що наш веб-сайт, або якийсь інший сервер помер, і нам треба відновити систему в іншому місці. Виконаємо повне відновлення всього сервера за допомогою раніше створеної резервної копії. Для цього нам знадобиться Veeam Linux Recovery Media, який ми завантажили раніше.

Для відновлення системи потрібно дотриматись двох обов'язкових умов:

  1. Готуємо новий сервер з диском, який повинен бути не меншим за диск вихідного сервера. Це обов'язкова умова, інакше відновлення системи навіть не розпочнеться. Veeam скаже, що розмір диска є недостатнім і не запропонує більше ніяких варіантів відновлення.
  2. Оперативна пам'ять для системи повинна бути не менше 1024 Мб. Якщо менше, завантаження з диска не буде виконано. Система скаже, що вона може розгорнути кореневий розділ.

Завантажуємося з диска. В розділі Configure networkпереконуємось, що мережа налаштована, отримано ip адресу, яка має доступ до інтернету. Далі вибираємо Restore volumes ->Add shared folder. Заповнюємо параметри доступу до сховища архівів.

Вибираємо там директорію з нашим архівом системи, яку відновлюватимемо. Далі буде показаний список завдань у лівому стовпці та список резервних копійу правому.

У моєму випадку там лише одна копія. Вибираю її. Далі ми бачимо ліворуч список дисків нашого сервера, праворуч диски резервної копії.

У мене ліворуч чистий диск, справа теж один диск, на який встановлений завантажувач і є один розділ із коренем системи. Вибираємо праворуч наш диск (не розділ з коренем!) і тиснемо Restore whole disk to.

Як приймач вибираємо порожній диск на новому сервері.

Натискаємо S (Start restore). Візард покаже список дій, які будуть виконані та попросить їх підтвердити натисканням Enter.

Робимо це та спостерігаємо за процесом відновлення сервера centos з бекапу.

Чекаємо на закінчення перенесення сервера, вибираємо перезавантаження і виймаємо завантажувальний CD. Завантажуємося з жорсткого диска.

Далі може бути багато різних варіантів. Якщо ви переносите сервер на той же гіпервізор, то проблем, швидше за все, не буде, і все заведеться відразу. Якщо гіпервізор інший, то можуть бути варіанти, залежно від ситуації.

Перенесення віртуальної машини з KVM на Hyper-V

У моєму випадку я переношу сервер із KVM на Hyper-V. Після завантаження системи я отримую таку картину.

Сервер починає нескінченно висіти у подібному стані з такими характерними помилками:

Warning: dracut-initqueue timeout startout timeout scripts a start job is running for dev-disk-by ......

Починаю розбиратися, в чому може бути справа. Звичайно, тут вирішення проблеми залежатиме від конкретної ситуації. А успішність вирішення від кваліфікації сісадміну. Я вже трохи поморочився з подібними переносами і приблизно уявляю, в чому тут може бути проблема. Частково я цю тему торкався, коли робив . Але там була інша проблема, пов'язана із кастомним ядром від Xen.

У нашій ситуації з перенесенням віртуальної машини з KVM на Hyper-V проблема в іншому. У нас змінилося ім'я диска. Нам потрібно змінити це ім'я в fstabта в конфізі grub. До купи я ще зібрав знову initramfs, але не впевнений на 100%, що в даному випадку це потрібно було робити. Я зробив про всяк випадок одразу все за один захід.

Отже, завантажуємося з інсталяційного диска CentOS 7 та вибираємо режим Rescue a CentOS system. Докладно про це розповідав у згаданій раніше статті із перенесенням від xen. Вибираємо перший режим запуску.

# fdisk -l

У мене це sda, а на минулому сервері він називався vda. Нам потрібно внести ці зміни до 2 файлів:

  1. /etc/fstab
  2. /boot/grub2/grub.cfg

Диск відновлення на самому початку міг сам змонтувати системний розділ у директорію /mnt/sysimage. Якщо він цього не зробить з якоїсь причини, зробіть це самі:

# mount /dev/sda1 /mnt/sysimage

Тепер нам треба зробити chroot у систему, попередньо змонтувавши туди інформацію про поточну систему. Виконуємо команди:

# mount --bind /proc /mnt/sysimage/proc # mount --bind /dev /mnt/sysimage/dev # mount --bind /sys /mnt/sysimage/sys # mount --bind /run /mnt/sysimage /run # chroot /mnt/sysimage

Ми завантажилися в оточення нашого сервера. Тут можна використовувати встановлений у вас на сервері текстовий редактор. З його допомогою змінюєте імена дисків у файлах /etc/fstabі /boot/grub2/grub.cfg. Можете просто автозаміною поміняти імена.

Тепер зберемо новий initramfs. Ідемо до директорії /bootі дивимося там останню версію ядра.

# cd /boot # ls -l | grep initramfs

У разі просто дивимося найвищі цифри. Зберемо новий initramfs відповідно до версії ядра.

# dracut initramfs-3.10.0-514.26.2.el7.x86_64.img 3.10.0-514.26.2.el7.x86_64

На завершення встановимо змінений завантажувач на наш диск:

# grub2-install /dev/sda

Перезавантажуємо сервер. Після цих змін, у мене все завантажилося. Перенесення віртуальної машини з KVM на Hyper-V виконане повністю. Причому, ми не мали доступу до образу системи. Хоча подібна помилка швидше за все виникла б, навіть якби ми конвертували і переносили готовий образ.

Висновок

Спочатку планував написати невелику замітку на тему використання Veeam для сервера бекапу. Але в процесі вдалося розібрати ще й перенесення сервера з одного гіпервізора на інший. Ще раз повторюся, кому це здалося надто складним. Якщо ви будете бекапит і відновлювати сервер в рамках одного і того ж гіпервізора, то описаних вище проблем у вас не буде. Все пройде гладко.

При перенесенні із заліза на віртуальну машину чи навпаки, теж швидше за все виникнуть якісь проблеми. Не існує софту або готового рішення, що дозволило б все це виконати в автоматичному режимі. З проблемами завантаження доведеться розбиратися в ході справи. Але дві основні проблеми я розібрав:

  1. Невідповідні версії ядер. Після перенесення потрібно буде перевстановити чи оновити ядро.
  2. Різні імена дисків або позначок розділів. Потрібно буде їх привести у відповідність до нового заліза.

Це найпопулярніші проблеми. З іншими мені не доводилося стикатися. Хоча не сказати, що мені часто доводилося переносити сервер, але деякий досвід є. Думаю, ця стаття буде багатьом корисна, тому що подібне перенесення не дуже розкрите в статтях в інтернеті. за Крайній мірімені не траплялися добрі гайди на цю тему. Розбираюсь зазвичай сам за допомогою гуглення за англомовним сегментом.

Діліться своїм досвідом та залишайте зауваження до статті або вказуйте на помилку у коментарях.

Онлайн курс "Адміністратор Linux"

Якщо у вас є бажання навчитися будувати та підтримувати високодоступні та надійні системи, рекомендую познайомитись з онлайн-курсом «Адміністратор Linux»в OTUS. Курс не для новачків, для вступу потрібні базові знання з мереж та встановлення Linuxна віртуалку. Навчання триває 5 місяців, після чого успішні випускники курсу зможуть пройти співбесіду у партнерів. Перевірте себе на вступному тесті і дивіться програму детальніше.

Незважаючи на важливість всього комплексу заходів із резервування, основним елементом все ж таки є програмно-прикладне забезпечення. Основними, найбільш популярними виробниками програмного забезпечення є VmWare, Acronis. Veeam.

Почнемо розгляд переваг із програмних продуктів, що виробляються компанією Acronis. Одним із них є Acronis Backup & Recovery Virtual Edition

Цей продукт підтримує всі основні платформи віртуалізації. Але для кожної із платформ існують свої специфічні особливості. Залежно від типу віртуалізації використовується один із агентів, що встановлюються на платформу. У зв'язку з деякими особливостями, це забезпечення здатне здійснювати резервування даних на низькому рівні та на рівні операційної системи. Низькорівневе копіювання передбачає отримання контролю над даними без установки агентів безпосередньо в гостьові системи. Тобто. система здатна здійснювати резервне копіювання та відновлення на рівні дисків та кластеризованих віртуальних машин, одночасне копіювання кількох віртуальних машин, підтримує міграцію та інкрементне відновлення віртуальної машини. У деяких випадках низькорівневе резервування може бути недоступним. Це зумовлено особливостями обмеження продукту віртуалізації. Для його обходу використовують копіювання зсередини гостьової операційної системи.

Для забезпечення цієї функції в гостьову систему встановлюється агент, який за функціоналом нічим не поступається агенту, встановленому на платформу. Локальний агент має практично ті ж функції, включаючи можливість перенесення машини у віртуальне середовище.

Але, навіть якщо встановити на платформу програмне забезпечення, що має відношення виробнику системи віртуалізації, це не означає повну сумісність і залучення всього спектра необхідних функцій.

Наприклад, компанія VmWare виробляє такий програмний продукт як VmWare Data Recovery для віртуальних машин на ESX. Зважаючи на те, що даний виробник лідирує у сфері віртуалізації, він мав за умовчанням посунути конкурентів із резервного копіювання у своїй галузі. Проте цього не сталося. Причиною цього є той факт, що цей продукт є відносно простим. Фактично він орієнтований на галузі, для яких безпека даних не є особливо критичною характеристикою та достатній найпростіший механізм резервування. VMware Data Recovery може створювати резервну копію віртуальної машини лише на рівні образу (файлів vmdk), а відновлювати може як образ цілком, так і окремі файли в гостьову ОС.

У промисловому середовищі більш-менш великих компаній, знадобляться такі функції як:

  • можливості швидкого відновлення образів
  • створення реплік ВМ швидкого відновлення.
  • інтеграція із засобами запису на стрічкові бібліотеки.
  • гнучкі (а не жорстко прошиті) політики повних, диференціальних та інкрементальних резервних копій.
  • покращені механізми стиснення та дедуплікації.
  • можливість відновлення окремих файлів.

Всі ці функції є у ​​Veeam Backup. Яка, фактично, і є найкращим рішенняму сфері резервного копіювання у сфері віртуалізації.

Цей продукт багатофункціональний, може виконувати більшість функцій, правда неабияка кількість додаткових параметрів є опціями, що підвищить його вартість при придбанні повного пакета. Але сама програма Veeam BackUp & Replication є закінченим продуктом, що використовується в багатьох компаніях, як малих, так і великих. Ця програма включає 2 модулі: створення резервних копій та їх реплікацію.

Коротко архітектура побудови резервного копіювання Veeam Backup виглядає так:

Veeam Backup сервер запускає завдання та визначає оптимальний Veeam Backup Proxy для копіювання даних. Veeam Backup Proxy витягує дані віртуальних машин vSphere, дедуплікує дані, архівує та потоком передає на Veeam Backup Repository. Veeam Backup Repository записує дані на диск у резервні копії, а також слідкує за політикою зберігання копій: наприклад, при необхідності збирає повні синтетичні копії.

Малюнок 38 Схематичне зображення принципу роботи сервісу

Veeam Backup Proxy при цьому може бути фізичним сервером або віртуальною машиною з ОС MS Windows, а способи вилучення даних можуть бути при цьому: через мережу SAN, через технологію VMware Hot Add або через мережу LAN.

Додатково забезпечення Veeam має досить великий перелік корисних можливостей. Виходячи з міркування, що для своєї системи ми зупинимо вибір саме на даному програмному забезпеченні, слід розглянути склад його технологій більш докладно.

Цей продукт повністю підтримує ESX та ESXi, включаючи такі функції, як « тонкі диски», Сhanged Block Tracking, vStorage APIs for Data Protection, vApp, HotAdd.

Крім стандартних функцій, передбачених у платформі віртуалізації, існують і специфічні, такі як Veeam Power. Дана технологія дає можливість запуску віртуальної машини прямо з файлу резервної копії, навіть якщо файл був стиснений і дедуплікований, без попереднього відновлення. Вона дозволяє скоротити час простою у разі аварії, запускати резервні копії для перевірки того, що копію було зроблено правильно (SureBackup). До пакету можуть увійти Veeam Backup Enterprise Manager – інструмент для централізованого керування резервним копіюванням, ліцензіями на Veeam BR, оновленнями.

Малюнок 39 Схематичне зображення принципу роботи сервісуVeeam Backup Enterprise Manager

Guest OS Files and VM Files Recovery – можливість відновлення окремих фалів та папок із резервних копій віртуальних машин. Що також у деяких випадках здатне значно скоротити час відновлення працездатності системи. Для відновлення одного або кількох пошкоджених файлів немає потреби відновлювати весь масив даних.

Incremental and Reversed Incremental backup – продукт Veeam має два методи резервного копіювання: інкрементний – швидший, який рекомендується для резервування диск-диск-стрічковий накопичувач, і назад інкрементний або синтетичний – рекомендується для резервування диск-диск і дозволяє зберегти повну резервну копію останнього резервування.


При додатковому («інкрементальному») резервуванні відбувається копіювання тільки тих файлів, які були змінені з того часу, як востаннє виконувалося повне або додаткове резервне копіювання. Наступне додаткове резервування додає лише файли, які були змінені з попереднього додаткового резервування. На відміну від диференціального резервування, зміни або нові файли не замінюють старі, а додаються на носій незалежно.

Рисунок 40 Схематичне зображення додаткового типу резервування.

Малюнок 41 Схематичне зображення інкрементного типу резервування.

Data De-Duplication and Compression – обидві технології дозволяють зменшити потрібне місце для резервного копіювання віртуальних машин. Дедуплікація дозволяє під час резервного копіювання кількох віртуальних машин не зберігати блоки, що повторюються, наприклад, коли резервується кілька операційних систем одного покоління.

Ще одна функція, яка дозволяє зменшити розмір резервних копій, це стиснення (compression). При використанні може збільшуватися час створення резервної копії та навантаження на апаратні потужності. І, нарешті, функція Reporting дозволяє формувати звіти роботи Veeam BR.

Таким чином, можна зробити висновок про те, що найбільш підходящим програмним продуктом для забезпечення надійності зберігання та обробки інформації та даних є продукт корпорації Veeam. Саме він володіє найбільш повним функціоналом, здатним задовольнити будь-якого, як завгодно вимогливого, користувача. А у безпосередній тісній інтеграції із вбудованим у систему віртуалізації забезпеченням для резервування, здатне практично повністю виключити негативні наслідки через виникнення аварійних ситуацій.

Немає подібних статей.

Будь-який офіс сповнений інформації. Найчастіше вона і є найдорожчим активом компанії. Погано, що про це згадують тоді, коли виникає реальний ризик її втрати. І навіть після збою, після відновлення лише частини інформації цей урок швидко забувається.

Інший адміністратор розведе руками і скаже: А що робити? Бюджету – ні, розуміння з боку керівників – ні, тому і бекапів у нас теж немає. Зламається - на їхній совісті. Але це лише половина лиха, адже зламати можете і ви самі. Неправильна конфігурація, помилка в налаштуванні, криптор (вірус-шифратор) і дані безповоротно втрачені. Тому бекапи робити потрібно. Досягши цього розуміння, можна приступати до практичної частини.

У цій статті ми розглянемо можливий підхід до резервного копіювання у типовому невеликому офісі, що працює на платформі Microsoft, та порекомендуємо кілька варіантів обладнання для зберігання копій. Звичайно, у великому офісі чи компанії все по-іншому. Там є і резервні СГД, і стрічкові бібліотеки, дорогі спеціалізовані продукти. А резервне копіювання датацентру – це і наука, і мистецтво, якому можна присвятити не лише статтю, а й усе своє життя.

Типи даних та способи їх резервного копіювання

Файлові сервери

Для оперативного відновленняфайлів без резервних копій зручно використовувати механізм тіньових копій - Shadow Copies of Shared Folders. Для його роботи зазвичай досить зарезервувати 5-20% дискового простору на самому файловому сервері. У розкладі для створення знімка (snapshot) можна вказати кінець робочого дня і опівдні. Резерв у 5% дозволяє зберігати близько 14 знімків, фактичне число залежить від обсягу диска та інтенсивності зміни даних.

Резервне копіювання можна виконувати вбудованим засобом Windows Backup. Також є досить надійні інструменти Cobian Backup та Handy Backup. Cobian Backup - безкоштовна програма, що підтримує Unicode, FTP, стиск, шифрування, інкрементальні та диференціальні види резервного копіювання. Handy Backup має ще більше можливостей, включаючи синхронізацію та відновлення даних із копій. Ми будемо розглядати роботу Windows Backup.

Слід пам'ятати, що у віддалену мережну папку на сервері резервного копіювання можна зберегти лише одну копію даних. І наступне завдання резервного копіювання її перезапише. Але в будь-якому випадку зберігати єдину копію даних - ризиковано.

Для обходу цього обмеження є простий та дієвий спосіб. Треба підключити диск для резервних копій із backup-сервера за протоколом iSCSI. Windows Backup вважатиме такий диск локальним.

Перша резервна копія дорівнюватиме обсягу даних, що зберігаються. Оскільки Windows Backup використовує блоковий, а не файловий спосіб резервного копіювання, наступна інкрементальна копія займе стільки скільки фактично змінилося дискових блоків.

Інкрементальне резервне копіювання – це запис лише змінених даних. Тобто не потрібно щоразу копіювати всю базу цілком, достатньо один раз створити її повну копію, а потім вносити до неї актуальні зміни. При цьому попередня версія даних не зберігається, Нова версіяпишеться поверх неї.

Диференціальне резервне копіювання, навпаки, передбачає збереження попередніх версій. Наприклад, щодня створюючи копію бази даних, ви зберігаєте усі попередні копії за тиждень. Це дозволяє швидко відкотитися до певного стану. Під час диференціального копіювання змінені дані записуються окремо від повної копії.

Windows Backup не потребує додаткового налаштування і повністю керує сховищем:

Automatic management of full and incremental backups. Ви не маєте багато часу, щоб скористатися повним і досконалим backups. Instead, Windows Server Backup will, by default, створити incremental backup що behaves як повний backup. Ви можете recover any item from single backup, але backup буде тільки робочий простір, необхідний для значного backup. В додаток, Windows Server Backup не потребує User Intervention в періодично рішення всіх backups до безкоштовного дискового простору для нових backups-oldder backups є автоматично deleted.


Доцільно виділити під резервні копії два обсяги даних, що фактично зберігаються. Цього буде достатньо для зберігання щоденних копій із глибиною приблизно півтора-два місяці. Частота – щодня.

Сервери Microsoft SQL

Сервери Microsoft SQL підтримують три типи резервного копіювання:
  • Повне. Копіюється база даних повністю.
  • Диференційне. Копіюються сторінки бази даних, що змінилися з попередньої резервної копії.
  • Інкрементальне. Копіюється журнал транзакцій (для баз у Full Recovery).
Необхідно визначити, як часто ми створюємо повну резервну копію.
Один із орієнтирів – тривалість резервного копіювання. Його потрібно виконувати у неробочий час або у вихідні. Операція резервного копіювання створює помітне навантаження на сервер. Якщо неможливо виконати повне копіювання вночі або робочого дня, то таке завдання виконують у вихідні.

Другий орієнтир – обсяг диференціальних копій та тривалість диференціального копіювання. Кожна наступна диференціальна копія стає більше, оскільки включає попередню. Чим більше часу минуло від останньої повної копії, тим нелінійно довше створюється інкрементальна. Адже для повної копії можна читати файли бази даних послідовно, а для інкрементальної треба зчитувати сторінки, що змінилися, у випадкових місцях.

p align="justify"> Періодичність інкрементального копіювання залежить від того, яку частину бази даних прийнятно втратити в результаті збою. Якщо ви готові втратити одну годину роботи (тобто відновити базу даних станом на годину назад), інкрементальне резервне копіювання необхідно виконувати один раз на годину. Можна частіше, але пам'ятайте про навантаження на сервер. Слід пам'ятати, що резервне копіювання бази – лише з способів забезпечити збереження даних. Якщо втрата даних неприпустима, як і простий під час відновлення даних, використовуйте такі механізми, як AlwaysOn і Log Shipping.

Важливе налаштування, яке потрібно одразу зробити на сервері – увімкнути компресію для резервних копій. Це скоротить обсяг резервних даних майже вдвічі. Слід мати на увазі, що при запуску резервного копіювання під файл резервних копій на диску буде зарезервовано обсяг, що дорівнює фактичному розміру бази за вирахуванням порожніх сторінок.

Рекомендація щодо об'єму на дисках, що виділяється, - не менше двох повних розмірів бази даних. Але це мінімальна вимога: часто бухгалтерам потрібно зберігати по повній копії бази за кожен із попередніх років, а також повні копії за попередні звітні періоди цього року. Також може знадобитися щодня робити копії з глибиною щонайменше місяць.

Типовий розклад:

Для реалізації плану можна створити "План обслуговування", що включає всі три типи завдань.

Сервери Microsoft Exchange

Цей продукт підтримує два типи резервного копіювання:
  • Повне. Копіюються повністю бази даних та журнали транзакцій.
  • Інкрементальне. Копіюються лише журнали транзакцій.
Важливо регулярно виконувати резервне копіювання, оскільки воно дозволяє видалити («обрізати») журнали транзакції для поштових баз, не що у режимі циклічного ведення журналів.

Windows Backup підтримує лише повне резервне копіювання Microsoft Exchange. Для мінімізації обсягу копій, що зберігаються, можна використовувати диск, підключений по iSCSI, за аналогією з файловим сервером.

Віртуальні машини

Більшість продуктів резервного копіювання дозволяють копіювати віртуальну машину з усіма дисками без використання агентів всередині операційної системи. Veeam Backup & Replication дозволяє виконувати повні та інкрементальні резервні копії, а також синтезувати нову повну копію, «накочуючи» інкрементальні на стару повну копію.

Безкоштовна версія дозволяє робити тільки повну копію, що негативно позначається на вікні резервного копіювання та об'ємі даних, що передаються. Обсяг резервних даних, що зберігаються на диску, можна скоротити, увімкнувши Windows Deduplication. Коли знімається копія з віртуальної машини, на диску зберігається файл .vib, і так для кожної віртуальної машини. Вони досить ефективно дедуплікуються. Вночі створили резервну копію, дедуплікувалися за день. Це багаторазово перевірена схема, але потребує використання платної версії продукту.

З урахуванням того, що Windows Deduplication працює в режимі постпроцессингу, рекомендація щодо об'єму на дисках, що виділяється для зберігання, - не менше трьох повних розмірів віртуальних машин. Частота копіювання залежить від сервера. Якщо це веб-сервер зі статичним вмістом, то немає сенсу копіювати його частіше ніж один раз на тиждень.

Основні вимоги до апаратного забезпечення

Дискова підсистема

Операції резервного копіювання, як правило, не висувають високих вимогдо системи зберігання даних. Шаблон запису основного завдання - лінійний, а високе навантаження зі випадковим профілем введення-виведення виникає лише під час дедуплікації резервних копій.

У вас є вибір між 2,5" SFF-дисками та 3,5" LFF-дисками. Важких причин, через які варто вибрати SFF-диски, ми не бачимо. Диски цього типу мають меншу ємність і коштують дорожче. Вони незамінні, коли потрібно зняти більше IOPS з одного сервера (удвічі більше дисків – удвічі більше IOPS). З цієї причини більшість пропонованих SFF-дисків - SAS зі швидкістю обертання шпинделя в 10 тис. оборотів.

Оптимальний вибір для сервера резервного копіювання - ємні диски SATA/SAS зі швидкістю обертання шпинделя в 7200 оборотів. При цьому диски SAS, в теорії, дають трохи більше IOPS, ніж їх SATA-родичі, тому якщо різниця в ціні незначна, то переважні саме вони. Проте загалом для серверів резервного копіювання набагато важливішим є час напрацювання дисків на відмову.

Якщо ви плануєте використовувати функцію, то очевидно, що продуктивність сховища резервної копії повинна відповідати робочому навантаженню. Гальмо машина часто ще гірше, ніж неробоча.

Якщо ви придбали програмний продукт для резервного копіювання, розмір резервної копії залежатиме і від способу зберігання даних на диску, і від ефективності вбудованих механізмів дедуплікації/компресії.

RAM та CPU

Вимоги до оперативної пам'ятіі процесору залежить від кошти резервного копіювання.
Наприклад, для популярного Veeam Backup & Replication вони такі:
  • Одне ядро ​​на кожне конкурентне завдання резервного копіювання
    (https://helpcenter.veeam.com/backup/hyperv/limiting_tasks.html)
  • 4 Гб пам'яті для роботи продукту плюс 500 Мб кожне конкурентне завдання резервного копіювання.
Насправді кожне конкурентне завдання резервного копіювання використовує кілька агентів - один для передачі даних, інший для стиснення, третій для дедуплікації резервних копій. Тим не менш, продуктивність хоста рідко стає вузьким місцем. Зауважте, що дедуплікація в Windows - блокова, зі змінною довжиною блоку і стисненням.

Результати фірмової дедуплікації Veeam досить скромні, ми вважаємо за краще робити це засобами Windows Server 2012 R2. Якщо ви плануєте використовувати дедуплікацію Microsoft, то необхідно орієнтуватися на наступні системні вимоги: 1 ядро ​​і 350 Мб пам'яті на один том, що дедуплікується. Рекомендований максимальний розміртоми – 2 Тб.

Диск розміром 1.5Tb, обсяг даних 720Gb, без дедуплікації дані займали б більше 1Tb.

Мережа

Мінімальна швидкість мережного інтерфейсу – 1Gbit/s. Важко знайти обладнання, яке відповідає цій вимогі, але може підвести комутатор – будьте уважні при виборі мережного порту. На 100mbit/s резервне 1 Tb даних триватиме від 28 годин, що виглядає відносно прийнятним. Але коли потрібно зробити додаткову копію протягом робочого дня, чекати у 10 разів довше – собі дорожче.

Можна спробувати збільшити швидкість за допомогою EtherChannel або кількох IP-адрес, але такі конфігурації складніші у супроводі, а підсумкова швидкість не завжди відповідає очікуванням.

Якщо ви використовуєте віртуалізацію VMware та виділену SAN мережу, платні продукти можуть суттєво підвищити швидкість копіювання, читаючи дані безпосередньо з VMFS томів (SAN Transfer).

Декілька тонкощів при виборі процесора та пам'яті ми розберемо у розділі про вибір сервера.

Простий NAS «бізнес-серії»

Типовий NAS - пристрій із закритою фірмовою прошивкою/операційною системою, призначений для зберігання файлів у невеликому офісі. У функції більшості сучасних NAS входить зберігання та роздача файлів за протоколами SMB/FTP/HTTP/iSCSI. Для конфігурування використається доброзичливий web-інтерфейс. Найчастіше виробники використовують фірмові технології створення RAID-масивів. Але за зручність доведеться заплатити. Бізнес-серія зазвичай відрізняється від домашніх пристроїв набірним процесором - замість ARM встановлюються продуктивніші Intel Atom або молодші Intel Core i3.

Типовий представник - NETGEAR RN314 ( Орієнтовна цінабез дисків – 50 000).

Плюси: відносно недорогий, можливість заміни дисків hot-swap, власний програмний RAID.
Мінуси: низька дискова ємність (4 диски), невисока продуктивність, неможливо встановити програмне забезпечення для резервного копіювання безпосередньо на пристрій.

Практично будь-які NAS, навіть найпростіші, дозволяють підключати iSCSI диски. Але під навантаженням вони працюють "не дуже", чим менше пам'яті в пристрої і більше об'єм дисків, тим більше може бути проблем. А латентність доступу настільки висока, що крім під бекапи такі диски не годяться, навіть файл-сервер гальмуватиме.

З приводу дедуплікації сама Netgear пише про те, що її не слід включати для iSCSI-пристроїв. З їхньої статті можна зробити висновок, що метод, який використовується в їхній залізці, дуже схожий на аналогічний Oracle ZFS. А ZFS відома тим, що для дедуплікації великого обсягу даних потрібна величезна кількість оперативної пам'яті, якої немає у цих скромних пристроях.

Що ж до Windows, то з пам'яті вимоги досить скромні. Але iSCSI-диск у форматі Windows Server – це VHD-файл. Дедуплікація VHD підтримується тільки для сценарію VDI (Virtual Desktop Infrastructure), тому для резервної копії треба перевіряти на свій страх та ризик. А ризикувати бекапами – остання справа.

Дедуплікація самих даних, що зберігаються в архівах Windows Backup, позбавлена ​​сенсу. Оскільки кожна диференціальна копія зберігає лише дані, що змінилися, то дедуплікувати нічого.

Ряд недоліків можна нівелювати покупкою трохи потужнішого і ємнішого пристрою - NETGEAR ReadyNAS 516.

6 дисків, Intel Core i3, з можливістю підключення до трьох додаткових модулів п'ятидисків. Проблема в ціні - без дисків пристрій коштуватиме 150 000 рублів.

Можна підібрати аналогічну за ціною модель у стійкому виконанні.

Швидкість пристроїв такого класу обмежена швидкістю двох найшвидших гігабітних мережевих інтерфейсів.

Просунутий NAS «корпоративного рівня»

Ці пристрої вже є серверами початкового рівня все з тією ж фірмовою прошивкою та програмним RAID.

Наприклад, Netgear RN4220S.

Двохюнітова модель підтримує 12 дисків із загальною сирою ємністю до 48 Тб. Два блоки живлення покращують стійкість до відмов, і ви не залишитеся без резервних копій, поки закуповується новий блок. Будучи укомплектованим лише простеньким Intel Xeon E3-1225v2 Quad Core 3,2 ГГц, 8 Гб RAM і двома слотами SFP+ для 10 Гбіт Ethernet, цей NAS обійдеться вам в 400 000 рублів без дисків. Це дуже дорого і не дуже гнучко, тим паче для невеликої компанії.

Сервери загального призначення

Звичайний сервер буде гарним варіантомякщо ви готові з ним повозитися. Незалежно від того, яку ви виберете операційну систему, Windows або Linux, перед вами відкриваються широкі можливості створення конфігурації під ваші потреби. Можна довірити зберігання даних хорошому RAID-контролеру з кешем, можна зібрати програмний масив на Windows Storage Spaces або ZFS – вибір за вами. На цей сервер можна встановити і саму систему резервного копіювання.

Вибираючи форм-фактор сервера, оптимально зупинитися на сервері заввишки 2U. У такому сервері, як правило, можна встановити 12 LFF (3,5") або 24 SFF (2,5") диска. Крім того, зараз стало популярним розташовувати в тильній частині сервера два слоти під SFF-диски. Їх можна використовувати під системний розділ або SSD-кеш.

Один чи два процесори? Серверні процесори можу містити на одному кристалі від 4-х до фантастичних 22-х ядер, тому для сервера резервного копіювання два процесори не є життєвою необхідністю.

Однак у деяких випадках два процесори можуть коштувати трохи дорожче або навіть дешевше, ніж один із аналогічною кількістю ядер. А встановивши лише один процесор, ви можете зіткнутися з тим, що працюватимуть не всі PCI-E слоти.

Приклад такого обмеження описано на сайті Intel. Lenovo теж попереджає, що в сервері x3650 з двопроцесорною материнською платоюпри однопроцесорної конфігурації ви взагалі отримаєте лише один слот:

З одним процесором, тільки два fixed onboard PCIe slots (Slots 0 and 4) може бути використаний (Slot 5 requires the second processor). An internal storage controller occupies PCIe slot 0.


Необхідно підібрати ту кількість ядер, яка оптимально відповідатиме продуктивності мережі та дискової підсистеми.

Наприклад, якщо у вас дві гігабітні мережеві карти, то в кращому разі сервер зможе передавати дані в два-чотири потоки до 100 Мб/сек. (Насправді один потік рідко перевищує 50-60 Мб/сек.). Для цього достатньо і 4-6 ядерних процесорів. Якщо ж сервер встановлена ​​10-гігабітна карта і конфігурація мережного обладнання дозволяє отримати відповідний потік, то наш вибір - не менше 8-12 ядер.

Необов'язково брати процесор топової серії, для нашого завдання більш ніж досить не найпотужнішого E5.

При виборі модулів оперативної пам'яті слід враховувати можливості багатоканальної роботи з пам'яттю (оптимально - один модуль на канал), а також кількість процесорів. На кожен процесор зазвичай ставиться однакова кількість модулів.

Яку модель сервера вибрати?

Якщо вибирати з серверів HP, то навіть стартова лінійка двоюнітових серверів HPE DL 180 Gen9 пропонує сервери з 12-дисковим кошиком. Для конфігурування сервера від вас не потрібно думати про потрібних кабелях, доступних роз'ємах та інших тонких моментах, в яких можна схибити. Майстер конфігурування допоможе зробити це без помилок.

З продукції IBM під сервер резервного копіювання підійде модель x3650 M5. У конфігурації TopSeller - 8871EAG всього 8 дискових слотів, вона буде коштувати дешевше, якщо вам не потрібно більше дисків. Найбільш підходяща платформа - стандартна модель 8871D4x. Для конфігурування сервера скористайтесь Standalone Solutions Configuration Tool (SSCT). Під час запуску програми не забувайте вибрати правильну країну.

Нарешті, з продукції третього виробника "великої трійки" - Dell - можна порекомендувати модель R510.

Вдалого резервного копіювання, бажаємо вашим даним перебувати в цілості та безпеці.

Теги:

  • резервне копіювання
  • бекап
  • backup
Додати теги

Олексій Бережний

Організуємо систему резервного копіювання
для малого та середнього офісу

Напевно, немає потреби говорити про важливість резервного копіювання. І не лише для великих організацій. Бізнес-інформація будь-якої, навіть найменшої, компанії потребує гарної та своєчасно зробленої резервної копії. Але далеко не кожна компанія може дозволити собі потужне та дороге рішення на базі дорогих стрічкових бібліотек та відомих програмних продуктів, таких як Symantec Backup Exec. Водночас, копіювати (а іноді й відновлювати дані) необхідно. З цієї ситуації сам собою напрошується нескладний вихід - створити систему резервного копіювання на базі безкоштовних програмних продуктів на базі Linux. Як зазвичай буває в невеликих компаніях, здати закінчену систему потрібно було ще вчора, тому основний акцент зробимо на простоті реалізації, а також на можливості делегування операцій резервного копіювання іншій особі, яка не має навичок досвідченого адміністратора UNIX-систем.

Що загрожує нашим даним

Безглуздо намагатися створювати систему резервування та відновлення даних без чіткого розуміння причин, які можуть призвести до втрати даних. Чинники ці можуть бути як зовнішнього, так і внутрішнього характеру.

Внутрішні фактори

До цих факторів можна віднести знищення даних у зв'язку із зараженням комп'ютерним вірусомвидалення даних у зв'язку з помилковими або навмисними діями користувачів, некоректною роботою програм, збоїв обладнання, кидків напруги та інших факторів, що мають локальний характер і викликані причинами, що виникли всередині офісу.

Зовнішні фактори

Досить докладний перелік даних факторів можна отримати, заглянувши на останні сторінкибільшості договорів, де вказуються форс-мажорні обставини, починаючи з розломів земної кори і закінчуючи діями третіх осіб.

Відповідно, якщо в офісі сталася пожежа або представники правоохоронних органів вилучили або опечатали обладнання, доступ до даних, що містять важливу для ведення бізнесу інформацію, буде припинено. (Тут особливо важливо розуміти, що резервна копія, покликана зберегти наші бізнес-процеси, повинна зберігатися поза територією офісу.)

Способи організації резервного копіювання

Існує кілька способів організації резервного копіювання.

Встановлення внутрішнього Backup-сервера

Захиститись від більшості внутрішніх факторів можна, встановивши спеціальний файловий сервер для створення та зберігання резервних копій. Таким чином, більша частина даних копіюється по мережі в період найменшого завантаження, найчастіше вночі на жорсткі дискисервера спеціально виділеного для зберігання резервних копій.

Переваги:дана система легко організується та вимагає відносно невеликих витрат. Достатньо комп'ютера з великим обсягом дискового простору. Даний комплект цілком можна використовувати як платформу при організації файл-сервера для зберігання резервних копій інформації з інших серверів та робочих станцій.

Недоліки:ця технологія не підходить для захисту від зовнішніх факторів, оскільки інформація зберігається біля підприємства. Також вона може виявитися марною у разі зараження комп'ютерним вірусом або шкідливого впливу інших осіб, оскільки Backup-сервер, що знаходиться у включеному стані і доступний по мережі, також може зазнати як вірусної, так і будь-якої іншої атаки.

Копіювання даних на змінний носій

Ця технологія передбачає наявність якогось пристрою, здатного писати змінні носії даних. У сукупності з фізичним транспортуванням носія, що містить свіжу копію даних, за межі підприємства (надалі цей прийом називатимемо off-site) рішення здатне забезпечити збереження даних у більшості випадків.

Переваги:захищає як від внутрішніх, і від більшості зовнішніх чинників.

Недоліки:потребує додаткового обладнання та програмного забезпечення для резервного копіювання. Уповільнюється процес відновлення даних у зв'язку з необхідністю зворотного транспортування носія на територію підприємства. Також вимагає наявності додаткових навичок у особи, відповідальної за збереження та відновлення даних.

Копіювання даних off-site за допомогою мережевих з'єднань

Цей метод полягає у копіюванні файлів через мережу за межі території підприємства. При цьому може використовуватись як пряме підключення, так і захищені інтернет-з'єднання (VPN).

Переваги:не потребує фізичного транспортування носія.

Недоліки:потребує швидкісного мережного підключення. Можливі проблеми при відновленні даних. При використанні інтернет-з'єднання плата за трафік може становити значну суму.

Підведемо підсумки

Найбільш раціональним є метод, що поєднує в собі наявність внутрішнього Backup-сервера і копіювання даних на змінний носій. У цьому випадку з'являється можливість значно розширити можливості нашої backup-системи, використовуючи технологію, коли дані вночі попередньо копіюються на Backup-сервер, а вже звідти вивантажуються на стрічку. Це дозволить розвантажити комп'ютерну мережута більш ефективно використовувати час, відведений для резервного копіювання. Так як при цьому backup-сервер інтегрований із системою копіювання на змінний носій, при його організації необхідно орієнтуватися на специфіку апаратних та програмних засобів, що використовуються при копіюванні даних на змінний носій.

Створення плану резервного копіювання

Розглянемо типи резервного копіювання.

Повне копіювання (Full backup)

Здійснюється копіювання даних у повному обсязі.

Переваги:самий надійний спосібрезервного копіювання. У разі виходу з ладу свіжої резервної копії частину даних все одно можна відновити з попередньої копії. Найефективніший метод швидкого відновлення інформаційної інфраструктури підприємства.

Недоліки:вимагає носіїв даних більшої ємності та тривалішого часу виконання.

Диференційне копіювання (Differential backup)

Копіюються лише зміни з моменту виконання останнього Full backup. Дані копіюються "наростаючим підсумком", так що остання копіяміститиме всі зміни з моменту останнього Full backup.

Переваги:виконується дещо швидше, ніж Full backup. Пошкодження однієї з копій не призводить до втрати всіх даних за період (за наявності дійсної копії Full backup).

Недоліки:так чи інакше, все одно потрібне регулярне виконання Full backup. У разі пошкодження носія з повною копією (Full backup) цей екземпляр резервної копії стає марним. Остання копія, що містить у собі зміни за тривалий період, може бути порівнянна за розмірами з Full backup.

Інкрементне копіювання (Incremental backup)

Виконується копіювання лише інформації, зміненої після виконання попереднього Incremental backup.

Переваги:найшвидший метод резервного копіювання. Займає найменше обсягу.

Недоліки:найненадійніший метод резервного копіювання. У разі пошкодження однієї з копій усі наступні копії стають марними. У разі пошкодження носія з Full backup стає непотрібним. Необхідно здійснювати off-site всіх копій Incremental backup за період. Відновлення даних триває тривалий час.

Підведемо підсумки

Тип копіювання зазвичай диктується фінансовим становищем та важливістю даних. Якщо дозволяє бюджет і дані є комерційною цінністю, краще використовувати Full backup.

Якщо бюджет мінімальний або дані не мають великої цінності, то можна використовувати Incremental backup.

Differential backup є певним компромісом, часто не завжди виправданим, оскільки може виявитися, що остання копія вимагає обсягу дискового носіяечас створення майже стільки ж, скільки і Full backup.

Створення системи резервного копіювання

Враховуючи величину обороту компанії, можна обчислити приблизну вартість одного бізнес-дня та відповідно важливість комерційних даних. У наших умовах доцільно зупинитись на наступному варіанті.

Як метод резервного копіювання використовуємо поєднання Backup-сервера та накопичувача на знімних носіях(наприклад, стрічкового накопичувача).

План резервного копіювання є щоденним Full backup попередньо на Backup-сервер з подальшим вивантаженням на стрічку і транспортуванням в безпечне місце (off-site) стрічкового носія даних (картриджа). У подібних системах Backup-сервер також називають кеш-сервером, прагнучи підкреслити його проміжне значення перед остаточним копіюванням на стрічку (див. рис. 1).

Планування процесу відновлення

Створення резервної копії – це, безумовно, дуже важлива частина системи захисту та відновлення даних. Але не менш важливо знати, як відновлюватимуться дані з резервної копії.

Тому при виборі системи резервного копіювання слід спиратися на стандартизоване рішення, яке підтримується більшістю виробників обладнання та програмного забезпечення.

Наприклад, таким рішенням є стрічкові накопичувачі (стримери), які підтримують стандарт LTO (Linear Tape Open), розроблений такими відомими учасниками комп'ютерного ринку, як IBM, HP та Seagate.

Приймемо за основу таку схему відновлення:

  • Дрібні, але термінові завдання відновлення даних, такі як реанімація зіпсованого помилково файлу, виконуються з кеш-сервера.
  • У разі виникнення серйозніших проблем, наприклад, коли потрібно відновити дані після серйозної аварії (після знищення великої кількості файлів комп'ютерним вірусом і т.д.), а також у разі необхідності отримання доступу до інформації за минулий періодбудемо відновлювати зі знімного носія, що зберігається у безпечному місці.

Централізований чи децентралізований метод?

Існує два методи організації отримання даних, що підлягають резервному копіюванню: централізований та децентралізований.

У першому варіанті за весь процес резервного копіювання відповідає єдиний програмний комплекс, який працює за технологією «клієнт-сервер». Тобто є центральний серверіз встановленим спеціалізованим серверним ПЗ та програми-клієнти резервного копіювання на комп'ютерах. Інформація, що підлягає резервному копіюванню, збирається за допомогою цих клієнтів. За такою схемою працює більшість відомих комерційних backup-систем, таких як Symantec Backup Exec. Також існують безкоштовні системи резервного копіювання, переважно на базі Open Source, наприклад Bacula, які також працюють за «клієнт-серверною» технологією.

Другий метод – децентралізований означає відсутність єдиного центру управління. У цьому випадку на кожному сервері встановлено окрему програму забезпечення резервного копіювання, за допомогою якої дані переносяться на інший носій або мережевий ресурс. За такою схемою працює, наприклад, програма ntbackup, що поставляється із сучасними операційними системами сімейства Windows.

У нашому випадку вибрано децентралізований метод резервного копіювання. Дані з Windows-серверів, яких у нашій мережі явна більшість, копіюватимуться за допомогою програми ntbackup на мережевий ресурс кеш-сервера, з серверів на базі UNIX-систем – за допомогою програми tar. Причина досить банальна: необхідно якнайшвидше створити працюючу backup-систему і делегувати повноваження щодо виконання рутинних операцій резервного копіювання іншій особі. Тобто система має бути максимально простою та зрозумілою, яка при цьому не потребує вивчення складного. програмного комплексу, Такого як Backup Exec або Bacula. Крім того, не буде потрібна інсталяція програм-клієнтів, так як і ntbackup і tar вже присутні у відповідних операційних системах.

Вибір програмного забезпечення для організації сервера резервного копіювання

В якості операційної системи було обрано Linux CentOS за його сумісність із широко відомою операційною системою Linux Red Hat Enterprise (RHEL), підтримку rpm пакетів та простоту встановлення та обслуговування. Коли готувалося дане рішенняз резервного копіювання, була доступна версія Linux CentOS 5.2, вже вийшла версія 5.3 (http://www.centos.org).

Для полегшення завдань управління та віддаленого адміністрування, а також для подальшого делегування повноважень іншим співробітникам (наприклад, адміністратору Windows-систем) будемо використовувати протокол RDP. Для цього встановимо програму xrdp для підтримки термінального доступу за допомогою RDP-клієнта. Для роботи xrdp потрібний піднятий VNC-сервер, тому ми повинні встановити його.

Примітка: xrdp у деяких реалізаціях не завжди коректно працює з тим чи іншим RDP-клієнтом. Наприклад, у випадку з xrdp-0.4.0-1.el5.rf для CentOS не підтримується робота з останньою версією RDP-клієнта, який постачається з Service Pack 3 для Windows XP. У таких випадках рекомендується користуватися програмою rdesktop, http://www.rdesktop.org (зокрема, її Windows-версією rdesktop.exe, завантажити яку можна за адресою: http://www.atomice.com/blog/?page_id= 9).

Для полегшення роботи з файлами можна встановити Midnight Commander – файловий менеджер, аналог відомого Norton Commander.

Ну і нарешті, необхідно встановити програмне забезпечення для підтримки роботи зі стрічковим накопичувачем: HP Data Protector Express Single Server Edition, сторінка проекту: http://h18000.www1.hp.com/products/storage/software/datapexp/sse/index. html.

Вибір обладнання для кеш-сервера

Як кеш-сервер був обраний старенький сервер SuperMicro у корпусі big tower.

Апаратне забезпечення сервера:

  • Материнська плата: Super X6DHE-XG2.
  • Об'єм ОЗУ: 1 Гб.
  • Дискові контролери:
    • контролер Adaptec Embedded Host Raid вбудований в материнську плату;
    • додатковий RAID-контролер LSI Logic MegaRAID Ser523 у форматі PCI-X-133 із чотирма портами для підключення SATA-дисків.
    • два жорсткі диски Seagate ST31000340AS ємністю 1 Тб, призначені для проміжного зберігання даних;
    • два жорсткі диски Seagate ST3500320NS ємністю 500 Гб для об'єднання в RAID1 та встановлення на них операційної системи;
    • RAID-контролер SCSI для підключення стрічкового накопичувача LSI Logic LSI20320-HP у форматі PCI-X-133 із зовнішнім SCSI-інтерфейсом;
    • Стрічковий накопичувач HP Storage Works Ultrium 1840LTO4 разом із кабелем для підключення до зовнішнього SCSI-інтерфейсу.

Коротко прокоментую вибір апаратного забезпечення. Як можна здогадатися з наведеної конфігурації сервера, його збирали з того, що було під рукою. А ось стрічковий накопичувач LTO4 разом із SCSI з контролером для його підключення та запасом змінних картриджів (касет) був придбаний окремо.

Підготовка кеш-сервера

Після того, як ми повністю визначилися з обладнанням та програмним забезпеченням, настав час втілити наш проект у життя.

Першим кроком установимо операційну систему на наш кеш-сервер. Так як в Linux-системах часто не підтримуються ті чи інші моделі host-RAID-контролерів, має сенс не ризикувати і для розміщення безпосередньо операційної системи зібрати RAID1 на базі наявного контролера відомої моделі LSI Logic MegaRAID Ser523 і двох SATA-дисків по 500 Гб. Два жорсткі диски по 1 Тб, що залишилися, ми підключимо до контролера на материнській платі без об'єднання в RAID-масив. Таким чином, сама операційна система та прикладне програмне забезпечення будуть встановлені на RAID1, а два окремих диски по 1 Тб призначені для зберігання тимчасових резервних копій.

Самі жорсткі диски по 1 Тб, призначені для зберігання проміжних копій, мають сенс підключити та розмітити під час встановлення системи. Створюємо на кожному із дисків по тому і використовуємо точки монтування /vol0 і /vol1 відповідно.

Встановлення операційної системи здійснюється у звичайному режимі. При установці програмного забезпечення як шаблон інсталяції вибираємо Server GUI. З віконних менеджерів вибираємо Gnome за його простоту та економічність.

З додаткових програмних пакетів необхідно встановити Samba для організації файлового сервера серед Windows, а також VNC-сервер для забезпечення роботи xrdp. Також рекомендується встановити пакети з категорії «Development: Development Libraries, Development tools, Legacy Software development», щоб мати можливість надалі інсталювати програмне забезпечення.

І ще встановимо супердемон xinetd, щоб мати можливість запускати програму SWAT для керування сервером Samba.

Відразу при інсталяції створимо обліковий запис (наприклад, backuper), з-під якого і буде проводитися робота з резервного копіювання (див. рис. 2).

Якщо з якихось причин не вдалося створити її відразу, надалі можна буде скористатися інструментом User Manager, який запускається з основного меню: System -> Administration -> Users and Groups (див. мал. 3).

Примітка: у разі неможливості скористатися програмою User Manager можна скористатися командою useradd з відповідними ключами.

Варто трохи сказати про основну концепцію налаштування програмного забезпечення у нашому випадку – максимально використовувати можливості графічного інтерфейсу. Більшість UNIX-гуру відразу б запустили улюблену оболонку (shell) командного рядка, почали вводити команди і редагувати конфігураційні файли. Але в нашому випадку має бути непростий процес передачі повноважень іншій особі, швидше за все, мало знайомому з роботою з інтерфейсом командного рядка в UNIX-системах. Тому все, що можна зробити через графічний інтерфейс, має бути зроблено саме так. Виходячи з цих міркувань ми створимо на робочому столі іконку для запуску Midnight Commander (див. рис. 4).

Як уже згадувалося вище, при налаштуванні Samba ми також не відхилятимемося від наміченої стратегії і скористаємося веб-інтерфейсом під назвою SWAT.

Оскільки SWAT запускається супердемоном xinetd, необхідно підредагувати файл./etc/xinet.d/swat

Ось як приблизно має виглядати файл після редагування:

# default: off

# description: SWAT є Samba Web Admin Tool.

# Use swat to configure your Samba server.

# Для використання SWAT, connect to port 901

# with your favorite web browser.

service swat

Port = 901

Socket_type = stream

Wait = no

User = root

Server = /usr/sbin/swat

Log_on_failure += USERID

Disable = no

Тепер можна запустити веб-інтерфейс. Набираємо в рядку браузера (наприклад, Mozilla Firefox) адресу http://127.0.0.1:901 та, ввівши ім'я користувача rootіз відповідним паролем, потрапляємо у вікно SWAT. Далі, скориставшись вкладкою Password, необхідно задати ім'я користувача для доступу до мережних ресурсів, що призначаються. Щоб уникнути додаткових проблем, настійно рекомендую використовувати ті самі ім'я та пароль користувача, які вже заведені в системі. Тому вводимо ім'я користувача backuper, той же пароль, що і при створенні користувача UNIX, і натискаємо кнопку Add New User, далі необхідно дозволити цей обліковий запис, тому натискаємо кнопку Enable User (див. рис. 5).

Примітка: Якщо програма SWAT не використовується, можна використовувати команду smbpasswd з ключами -a для додавання та -e для дозволу облікового запису користувача Samba.

Для того, щоб мати можливість гнучкіше розпорядитися дисковими ресурсами (наприклад, надалі прибрати деякі файли із загального доступу, перенісши їх в інший каталог), створимо на підключених дисках vol0 і vol1 каталоги /vol0/backup0 та /vol1/backup1. Для того, щоб користувач backuper мав доступ до цих ресурсів, змінимо власника каталогу на backuper і поставимо відповідні права. Для цього досить зручно використовувати Midnight Commander.

Примітка: у разі неможливості скористатися програмою Midnight Commander потрібно використовувати команди: mkdir – для створення каталогу, команди chmod та chown – для зміни дозволів та зміни власника (групи) відповідно.

Якщо з якихось причин не вдалося відразу створити необхідні розділи і підключити диски, щоб зробити це після інсталяції, доведеться трохи попрацювати в командному рядку.

Запускаємо програму Terminal або будь-яку іншу оболонку командного рядка. При необхідності переходимо в режим суперкористувача root:

# su

Файли пристроїв: /dev/sda, /dev/sda1, /dev/sda2 та /dev/sda3 нас не цікавлять, тому що відносяться до вже підключеного дискового масиву RAID1 з операційною файловою системою. А ось /dev/sdb і /dev/sdc якраз і є файлами пристроїв тих самих дисків, які потрібно підключити.

Якщо виникли труднощі з визначенням, який файл пристрою якому диску належить, можна скористатися командою fdisk з параметром -l:

#fdisk -l

Disk /dev/sda: 500.0 GB, 500093157376 bytes

255 heads, 63 sectors/track, 60799 cylinders

/dev/sda1 * 1 5222 41945683+ 83 Linux

/dev/sda2 5223 6266 8385930 82 Linux swap / Solaris

/dev/sda3 6267 60799 438036322+ 83 Linux

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Для створення необхідного розділу на диску викликаємо програму fdisk:

# fdisk /dev/sdb

Спочатку програма видає повідомлення, подібне до цього:

Device contains neither a valid DOS partition table, nor Sun,

SGI або OSF disklabel

Building a new DOS disklabel. Changes will remain in memory only,

until you decide to write them. After that, of course,

the previous content won't be recoverable.

Номер cylinders для цього диска набір до 121601.

There is nothing wrong with that, але this is larger than 1024,

and could in certain setups cause problems with:

1) software that runs at boot time (e.g., old versions of LILO)

2) booting and partitioning software від інших OSs

(e.g., DOS FDISK, OS/2 FDISK)

Warning: invalid flag 0x0000 of partition table 4

will be correctod by w(rite)

Створюємо новий розділ:

Command (m for help): n

Перевіряємо список створених розділів:

Command (m for help): p

У відповідь програма видасть інформацію про створені розділи:

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/sdb1 1 121601 976760001 83 Linux

Записуємо зміни та виходимо з програми:

Command (m for help): w

The partition table має бути altered!

Calling ioctl() to re-read partition table.

Syncing disks.

Створюємо файлову системуна новому дисковому розділі:

# mkfs.ext3 /dev/sdb1

Оскільки файлова система ext3, що використовується нами, є журнальною, немає потреби перевіряти її перезавантаженням. Відключаємо цю функцію:

# tune2fs -c 0 -i 0 /dev/sdb1

Створюємо каталог для монтування новоствореного розділу з файловою системою:

# mkdir /vol0

І монтуємо файлову систему:

# mount -t ext3 /dev/sdb1 /vol0

За аналогією розмічаємо та монтуємо другий диск (/dev/sdc).

Для того, щоб створені нами розділи автоматично монтувалися під час запуску, необхідно відредагувати файл /etc/fstab. Приклад файлу /etc/fstab:

# vi /etc/fstab

LABEL=/ / ext3 defaults 1 1

/dev/sdb1 /vol0 ext3 defaults 0 0

/dev/sdc1 /vol1 ext3 defaults 0 0

tmpfs /dev/shm tmpfs defaults 0 0

devpts /dev/pts devpts gid=5,mode=620 0 0

sysfs /sys sysfs defaults 0 0

proc /proc proc defaults 0 0

LABEL=SWAP-sda2 swap swap defaults 0 0

Далі, знову скориставшись SWAT, створюємо спільний ресурс для резервних копій. Переходимо на вкладку Share. Далі задаємо ім'я ресурсу: у разі backup0. Вказуємо шлях до каталогу: у нашому випадку /vol0/backup0 та користувачів, які мають право доступу до каталогу valid users та admin users (див. рис. 6).

В кінцевому рахунку конфігураційний файл Samba – smb.conf має виглядати приблизно так:

Workgroup = VAI.LAN

Server string = Backup Server LTO4

Passdb backend = tdbsam

Username map = /etc/samba/smbusers

Ldap ssl = no

Cups options = raw

Comment = All Printers

Path = /var/spool/samba

Printable = Yes

Browseable = No

Comment = Backup0

Path = /vol0/backup0

Valid users = backuper

Admin users = backuper

Read only = No

Browseable = No

Comment = Backup0

Path = /vol1/backup1

Valid users = backuper

Admin users = backuper

Read only = No

Browseable = No

Де vol0 і vol1 – власне і є диски по 1 Тб для зберігання резервних копій.

Ну і нарешті переходимо до налаштування програмного забезпечення для резервного копіювання на стрічку - HP Data Protector Express Single Server Edition. Для початку зайдемо на сторінку програми http://www.hp.com/go/dataprotectorexpress/sse для реєстрації та отримання ключа (valid key). Маленький секрет – бажано використовувати MS Internet Explorer, тому що в інших браузерах скрипт може працювати некоректно (наприклад, мені вперше з Mozilla Firefox 3.0 та OpenSUSE Linux 11.1 ключ отримати не вдалося). Відповівши на необхідні запитання та отримавши на e-mail із valid key, приступаємо до встановлення програми.

Для цього входимо в систему як користувач backuper, вставляємо CD із програмою, отримуємо доступ до CD (при необхідності монтуємо носій) та запускаємо програму Terminal (командний рядок).

Набираємо команду su та вводимо пароль користувача root для переходу в режим суперкористувача. І, перейшовши до каталогу з примонтованим CD, запускаємо програму install. Запуститься вікно інсталяції програми (див. мал. 7).

У принципі, тут особливо описувати нічого. Установка програми відбувається штатним шляхом, з використанням зрозумілого графічного інтерфейсу.

Наприкінці програма-інсталятор запропонує запустити HP Data Protector Express Single Server Edition.

На жаль, оскільки програма була запущена з-під облікового запису root, то ярлик для запуску програми також був створений у домашньому каталозі користувача root. Для усунення цього нюансу потрібно лише скопіювати ярлик з робочого столу (Desktop) з домашнього каталогу root на робочий стіл користувача backuper та призначити відповідні права.

Створення запланованого завдання з резервного копіювання

Як було описано вище, резервне копіювання на стрічку виконуватиметься щодня за схемою Full Backup. Тому ми не вирішуватимемо питання, пов'язані зі складною схемою планування, ротацією носіїв тощо. Все, що нам потрібно, це створити завдання з повного копіюваннявибраних каталогів кеш-сервера на стрічку щодня, причому стрічковий носійбуде щоразу перезаписано.

Для початку запускаємо програму HP Data Protector Express Single Server Edition.(Якщо програма вже запущена, цей крок можна пропустити.)

Під час старту програми потрібно ввести пароль доступу. За промовчанням реквізити доступу: сервер localhost, ім'я користувача admin, без пароля (див. рис. 8).

Далі запуститься головне вікно програми. Потрібно віддати належне розробникам – програма має простий і зрозумілий інтерфейсбільшість операцій виконується за допомогою «помічників» (Wizards) (див. рис. 9). Для отримання інформації щодо роботи з програмою на інсталяційному диску є докладна документація.

За замовчуванням під час запуску програми одразу відкривається розділ Wizards. (Для переходу в цей розділ можна скористатися іконкою Wizards у правій частині вікна.) Клацаємо на значку Backup і переходимо у вікно вибору способу копіювання. Клікаємо на нижній іконці в лівій частині вікна Backup Specific і переходимо у вікно Wizard - Welcome. В полі Enter the name for the commanf being createdвводимо ім'я нашого завдання та клацаємо кнопку Next.

Тепер ми потрапляємо у вікно Select files and folders, де вибираються файли та каталоги, що підлягають копіюванню на стрічку.

Після натискання кнопки Next з'являється вікно Device Options. Тут необхідно вибрати пристрій, що використовується (Device to be used), а також встановити деякі параметри: «Автоформатування» (Auto format – Auto format mode), «Ім'я нового носія» (New media name) та ін. (див. рис. 10) .

Знову натискаємо кнопку Next. У вікні Job Options задаємо наступні параметри (див. рис. 11):

  • Backup Mode – Full(Будемо створювати повний бекап).
  • Auto verify mode – Quick verify (режим автоперевірки. За замовчуванням стоїть Full verify, але режим повної перевіркиархів займає досить тривалий час, порівнянний з часом виконання копіювання, тому в даному випадку обмежимося перевіркою на читання носія, враховуючи той факт, що ми щодня створюємо повну копію даних. Слід пам'ятати, що для твердої впевненості як записана копія слід обов'язково використовувати режим Full verify).
  • Span mode – Splitфайл.Якщо файл занадто великий для використання на одному носії, використовувати кілька носіїв. В іншому випадку, при виборі Restart file, програма проситиме помістити в накопичувач інший носій більшого розміру.
  • Зміна режиму – Prompt to another media. Якщо програма не виявляє необхідний носій, вона надсилає попередження з проханням завантажити носій у накопичувач.

Малюнок 11. Вікно Job options

Вікно Encryption/Compression з'являється відразу після Job options. Тут задаються параметри шифрування (encryption) та стискування (компресії). Слід зазначити, що заявлений об'єм для LTO (1,6 Гб для LTO4, 800 Мб для LTO3 тощо) буде доступний тільки при включенні апаратного стиснення. (І то за умови, що інформація на носії може бути успішно стиснута).

Передостаннє вікно – Shedule job, як і слідує за назвою, служить для планування виконання завдання у потрібний час. Так як ми збираємося лише запускати Full backup у потрібний час, при цьому просто перезаписуючи вставлений носій і не звертаючи уваги на додаткові нюанситипу ротації носіїв, то обмежимося найпростішим розкладом.

Для цього вибираємо:

  • Shedule type – Run repeatedly. Для створення налаштувань розкладу.
  • Start time – 10:30.Час старту завдання. До цього часу у нас у будь-якому випадку має завершитися нічний Full backup з робочих серверів на кеш-сервері.
  • Start date – 15/05/2009.Дата початку бекапу.
  • Rotation type - No rotation. У нашому випадку ротація носіїв не потрібна.

І в останньому вікні Copy Policy залишається натиснути кнопку Finish.

Все, завдання з резервного копіювання створено. Залишилося проконтролювати його виконання, і, за необхідності, внести коригування задля забезпечення необхідної функціональності.

Перевірка можливості відновлення з резервної копії

Для перевірки можливості відновлення надійдемо таким чином. Скопіюємо на касету один невеликий файл, а потім спробуємо відновити його.

Для цього знову перейдемо у вікно Wizards та виберемо іконку Restore. Це приведе нас у наступне вікно, де нам буде запропоновано лише один-єдиний метод відновлення Restore Specific. Тиснемо на однойменну іконку і переходимо у вікно Select files and folders. Тут вибираються файли, що підлягають відновленню.

Після натискання кнопки Next ми переходимо у вікно Device options, в якому власне і вибирається пристрій та носій, з якого будуть відновлюватись файли.

Далі на кнопці Next перед нами з'являється вікно Job options. Основна деталь, на яку треба звернути увагу, – прапорець Restore files that are in use (чи відновлювати файли, що використовуються в Наразі). Додаткові параметри, що встановлюються у вікні Advanced options, що викликається натисканням однойменної кнопки, в більшості випадків краще залишити без зміни (див. рис. 12).

Малюнок 12. Вікно Job options з відкритим вікном Advanced options

Ну і, нарешті, вже знайоме нам вікно планувальника Shedule job.

Звичайно, дуже засмучує той факт, що програма позбавлена ​​можливості відновлювати файли в інше місце (як мінімум, мені особисто так і не вдалося виявити цю функцію). Доведеться враховувати цей факт у роботі та перейменовувати файли та каталоги, які бажано не затирати під час відновлення з резервної копії.

Налаштування ntbackup

Незважаючи на те, що у світі існує досить велика кількість програм резервного копіювання для операційних систем сімейства Windows, програма ntbackup продовжує користуватися популярністю в першу чергу за безкоштовність і простоту використання. Розглянемо маленький приклад створення тестового завданнярезервного копіювання.

Для запуску програми достатньо в рядку запуску "Виконати" (Run) меню "Пуск" (Start) ввести ім'я програми ntbackup і натиснути .

Якщо програма запускається вперше, вона видасть вікно запуску майстра (Wizard). Користуватися ним не дуже зручно, тому ми відмовимося від його використання, знявши позначку "Завжди запускати в режимі майстра".

Далі у вікні «Архівація та відновлення» ми вибираємо пункт «Архівація файлів та параметрів» та переходимо до наступного вікна: «Що слід архівувати». Залежно від мети резервування вибираємо один із двох пунктів: «Усю інформацію на даному комп'ютері» або «Надати можливість вибору об'єктів для архівації» (у нашому випадку відзначаємо другий пункт). Далі переходимо у вікно вибору об'єктів, що підлягають резервному копіюванню.

Відзначивши необхідні пункти, натискаємо кнопку «Далі» і переходимо до наступного вікна «Ім'я, тип і розташування архівації», де вказується ресурс, на який буде копіюватися (ми вказуємо адресу і розшарований ресурс нашого кеш-сервера).

З'явиться вікно "Завершення майстра архівації та відновлення". Якщо більше нічого не потрібно налаштовувати, можна натиснути кнопку «Фініш», і процес резервного копіювання відразу ж запуститься, при цьому більшість параметрів буде встановлено за замовчуванням. Але оскільки ми хочемо створити заплановане завдання, ми натискаємо кнопку «Додатково» та продовжуємо налаштування.

У вікні "Тип архіву" вибираємо який архів ми будемо робити: "Звичайний" (Full backup), "Додатковий" (Differential), "Розносний" (Incremental) і т.д. Наступне вікно пропонує вибрати «Спосіб архівації».

Призначити метод копіювання та вказати мету (файл або пристрій). Далі завдання можна або запустити відразу, або запланувати певний час. Під час планування завдання у «Планувальнику» Windows (Windows Sheduler) з'явиться завдання у вигляді командного рядка з довгим переліком параметрів. (Яку за бажанням можна вставляти в скрипти і т.д.). Крім усього іншого, дана програмавміє коректно копіювати відкриті файли. Як кажуть – «дешево та сердито». Цю програму ми будемо використовувати для збору інформації з серверів, які працюють під Windows.

Завершальне налаштування системи резервного копіювання

Після налаштування кеш-сервера та системи запису на стрічку залишилося небагато. Перевірити доступність мережевих ресурсівна нашому сервері резервного копіювання, налаштувати локальне програмне забезпечення для створення резервних копій.

Ще потрібно обов'язково скласти розклад резервного копіювання, призначити відповідальних осіб та передати їм відповідні повноваження.

Висновок

Немає сумніву, що резервне копіювання – важливий аспект у роботі ІТ-структури будь-якої компанії. І незважаючи на жорсткі економічні умови, проте можливо створити прийнятну систему резервного копіювання, витративши мінімум коштів на придбання необхідних компонентів (стрічкового накопичувача і касет). При цьому створена система дозволяє делегувати повноваження іншій особі та за необхідності легко відновлювати втрачені дані.



ПОХОДЖЕННЯ СТАТТІ