Простий сервер резервного копіювання. Вибір обладнання для резервного копіювання у невеликому офісі

розробник 80-го рівня 10 листопада 2012 о 02:21

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

  • Чулан *

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

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

Розглянемо резервне копіювання у межах сервісів.

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

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

2. Резервне копіювання веб-сайтів
Хоча хостинг досить надійна штука – мати бекапи під рукою на випадок відкочування версії назад, або термінового відновлення сайту на іншому майданчику хочеться завжди. Скажімо навіть так: бекапи роблять і самі хостери, але зазвичай ці бекапи зберігаються не довго, зроблені у своєму форматі, недоступні, коли хостер лежить. У цих випадках тримати актуальну версію сайту у зручному для вас форматі на окремому технічному майданчику – мрія параноїка.
Сайт складається з двох частин: база даних та файли. Бекапі обидві. Технічно автоматичне резервне копіювання сайту відбувається так: щоночі в заданий час бекап сервер звертається до веб-сервера з проханням віддати бекап, який у свою чергу архівує дамп БД і файли, і пересилає все на бекап сервер.
Можна створити резервну копію сайту вручну. На панелі управління нашої CMS є чарівна кнопка “бекап”, за натисканням якої створюється архів і надсилається на бекап сервер. Залежно від розміру сайту (через 5 секунд, або 20) резервна копія вже знаходиться в надійному місці, а вам на пошту надходить звіт про її успішне завершення або помилку (якщо така є).

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

4. Резервне копіювання даних користувача.
В ідеальному варіанті всі дані користувача знаходяться в системі зберігання даних (СХД) і надійно захищені. Але це далеко не завжди так. Особливо ситуація ускладнюється, якщо підприємство має кілька маленьких офісів або є віддалені співробітники. У такому випадку можна налаштувати резервне копіювання найважливіших даних безпосередньо з робочих машин або локальних файлових серверів. Якщо кількість даних велика та вимірюється гігабайтами, можна організувати локальний сервер резервного копіювання. Або у випадку, якщо використовується домен Windows - файловий сервер для зберігання профілів користувача.
Для сучасної взаємодії нині використовуються хмарні сховища інформації. Дані з Google Drive теж мають сенс резервувати, т.к. власник може видалити дані, і в тих, хто їх спільно використовує нічого не залишиться. Ми періодично резервуємо Google документи за допомогою програми GDocBackup та відповідного скрипту який архівує з паролем і відправляє на сервер резервного копіювання.

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

Що таке наш бекап сервер?
Фізично сервер встановити дуже просто, набагато складніше та цікавіше організувати систему резервного копіювання. Жорсткі диски поставили в RAID-1 для забезпечення дзеркалювання даних, налаштували звіт на email при виході з ладу одного з дисків. Процесор – Intel Atom, просто і дешево, адже завдання сервера – лише зберігати дані. А точніше ночами отримувати кілька десятків гігабайт, а на запит (зазвичай вдень) віддавати кілька гігабайт. Сервер розміщений у серверній кімнаті, запитаний через джерело безперебійного живлення та підключений до Інтернету через оптичний кабель.
Використовується операційна система Linux Debian, що забезпечує стабільність роботи.

Ваші дані можуть зашифрувати вірус, вони можуть безслідно канути на несправному жорсткому диску. Кілька годин роботи над одним файлом можуть бути загублені при ненавмисному збереженні поверх нього іншого документа.

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

Ті файли, які вам не потрібні зараз, напевно можуть вам знадобитися завтра або через 5 років. А де ці файли? — Та на старому комп'ютері/флешці/відформатованому знімному носії…

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

Як це зробити, якщо у вас невелика фірма або особистий ПК, а грошових коштів обмежена кількість?

1 #. Резервне копіювання даних на кожному окремому комп'ютері:

На робочих станціях користувачів має бути настроєно тіньове резервне копіювання штатними засобами windows. (У windows 7 робиться через властивостізначок комп'ютер > Додаткові параметри системи > Захист системи). Можна увімкнути як бекап реєстру при змінах (контрольні точки), так і збереження станів файлів на локальних дисках. Доведеться пожертвувати вільним місцем на HDD, але нерви дорожчі.

Після небажаних (ненавмисних) змін папки або файлу можна буде відновити попередній стан.

Якщо штатне резервне копіювання не може бути використане з якоїсь причини, можна скористатися стороннім софтом таким як acronis backup and recovery (платний) або (безкоштовний). Програм на цю тему – маса.

Однак, резервне копіювання даних у межах одного фізичного диска не позбавить вас небезпеки його виходу з ладу. Важко оцінити цінність бекапу, коли він разом із вихідними даними знаходиться в битих секторах на HDD:)

Скажімо, так — резервне копіювання системи штатними засобами: «must have». Але важливі речі постарайтеся дублювати у мережу. Для цього можна:

а) Скористатися хостингом VDS (найдешевший тариф з 5ГБ простору 100 р. на місяць)

б) використовувати безкоштовне місце на хмарних сервісах (google drive, icloud, yandex disk тощо). Наприклад, гугл диск підтримує відновлення попередніх версій файлів. І навіть якщо ненавмисно змінений файл вже синхронізований, його завжди можна відновити. Можете прочитати корисні поради щодо google drive.

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

2 #. Резервне копіювання даних фірмі з кількома (і більше 10) робочими станціями.

Ідеальним варіантом для резервного копіювання на підприємстві буде наявність централізованого сервера всередині компанії (FTP сервер з RAID 1) або її межами (VDS сервер зі службою FTP).

Зберігати, скажімо, базу даних 1С чи договору Google-диску не зовсім безпечно, т.к. втративши доступ до пошти або якщо доступ опинився в руках зловмисників фірма безперечно постраждає. Хоча автор має знайомих індивідуальних підприємців, які тільки так і працюють. В останніх на гугл-диск все міститься в зашифрованому вигляді;)

а) У випадку із сервером усередині компанії необхідні разові витрати на сам файловий сервер (50-100 тис. руб) залежно від рівня надійності. Потім витрати можуть виникати при поломці заліза (що не часто). Також зважте на витрати на електроенергію.

б) У випадку із зовнішнім сховищем на VDS, ви платите 1 раз за налаштування адміністратором з ІТ-аутсорсингу (в районі 5 тис. руб, залежно від кількості комп'ютерів для бекапу) і щомісяця 500-900 рублів (залежно від обсягів інформації) за хостинг VDS Врахуйте, що в цьому випадку потрібен інтернет спритніший. Хоча б 5 Мбіт/с вихідної швидкості.

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

Нижче схематично представлені варіанти резервного копіювання для невеликого підприємства 5-30 комп'ютерів.

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

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

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

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

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

Програмне забезпечення як варіант можна використовувати Areca (кросплатформна java-додаток) + планувальник завдань Windows. В Areca створюється скрипт з параметрами резервного копіювання (куди копіювати, шифрування, вид та імена копій) який додається до планувальника задач windows або cron Unix. Можете ознайомитися зі статтею .

Як здається автору, варіант б) кращий, адже у компанії майже пропадає головний біль щодо збереження резервних даних. Але тут теж є пара мінусів: якщо ви використовуєте VDS для бекапу, то цей сервер вже ні з чим не поєднати. Можна звичайно туди помістити і ваші додатки (1с), але тоді, крім дискового простору, вам доведеться платити ще й за додатковий процесорний час і пам'ять (а це вже інші суми).

Ще один очевидний мінус - це. І за відсутності осудного провайдера поблизу вам залишається лише варіант а).

Отже другий варіант з VDS(б):

Дані йдуть у тому ж напрямі, як і на першій схемі (на малюнку не показані), проте тепер все відправляється через інтернет на віддалений VDS-сервер. Areca відмінно шифрує дані ще на стороні користувача і вони в такому вигляді розміщуються на VDS протоколом FTP. Як FTP-сервер на VDS Можна досить швидко підняти vsftpd , приклад його налаштування є .

Варто врахувати один нюанс: "Копіювання файлів по протоколу ftp з SSL або TLS - значно уповільнює процес, а при великих обсягах даних може зависнути зовсім".

Потрібно лише продумати політику резервного копіювання, а саме: «Збирати всі важливі дані спочатку всередині мережі на якомусь мережевому сховищі (загальна папка, наприклад) і потім під одним обліковим записом FTP скидати їх на VDS у призначений час. Або скидати дані з усіх комп'ютерів у час під різними обліковими записами». Перший варіант буде краще якщо комп'ютерів більше 5. Якщо ж мережа невелика, то й окреме мережеве сховище виділяти не потрібно.

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

Користувачі, які прочитали цей запис, зазвичай читають:

Вконтакте

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

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

Архітектура резервного копіювання сервера та робочих станцій

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

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

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

Крім копіювання файлів, програмою передбачено резервне копіювання фізичних серверів, бекап віртуальних машин Hyper-V, VMware Workstation та інших, резервне копіювання Exchange Server, MSSQL, MySQL/MariaDB, PostgreSQL, Oracle, Lotus Notes на серверах та робочих станціях, а також бекап будь-яких ODBC-сумісні бази даних на сервері.

Мережевий Агент Handy Backup(Network Agent) встановлюється на кожен комп'ютер, дані якого необхідно копіювати. Клієнт працює як служба Windows, не має графічного інтерфейсу, і дозволяє програмі збирати дані для резервного копіювання з серверів та робочих станцій користувачів.

Як працює мережеве резервне копіювання

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

Окрім резервування інформації мережевих комп'ютерів - файлів і папок, образів дисків, можна робити бекап баз даних (1С, MySQL, Oracle та ін), даних MS Exchange та Lotus Notes, що зберігаються на сервері. Також програма дозволяє виконувати резервне копіювання VMware, Hyper-V та інших віртуальних машин.

Handy Backup Server Network складається з Панелі Управління та Агентів:

* Включає Панель Управління і один Мережевий Агентдля бекапу сервера (встановлюється на тому ж комп'ютері, де Панель Управління).


Сервер та Мережі Агенти Handy Backup працюють під ОС Windows 10/8/7/Vistaабо 2016/2012/2008 Server.

Відгук користувача про Handy Backup

"Із задоволенням користуюсь Handy Backup - продуктом для створення та відновлення копій програм та даних. Є можливість зберігати дані не лише з одного комп'ютера, а й із різних робочих місць . Приваблює надійна робота, дружній інтерфейс, можливість підтримки. Програма може виконувати роботу за розкладом, зберігати та відновлювати дані на різних пристроях."

В.І.Кріш, Провідний програміст ТОВ КБ "Пласт-М"

Незважаючи на важливість всього комплексу заходів із резервування, основним елементом все ж таки є програмно-прикладне забезпечення. Основними, найбільш популярними виробниками програмного забезпечення є 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 API 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. Саме він володіє найбільш повним функціоналом, здатним задовольнити будь-якого, як завгодно вимогливого, користувача. А у безпосередній тісній інтеграції із вбудованим у систему віртуалізації забезпеченням для резервування, здатне практично повністю виключити негативні наслідки через виникнення аварійних ситуацій.

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

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

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

Напевно, немає потреби говорити про важливість резервного копіювання. І не лише для великих організацій. Бізнес-інформація будь-якої, навіть найменшої, компанії потребує гарної та своєчасно зробленої резервної копії. Але далеко не кожна компанія може дозволити собі потужне та дороге рішення на базі дорогих стрічкових бібліотек та відомих програмних продуктів, таких як 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.

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

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

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

Висновок

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