Сервер резервного зберігання з ZFS

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

Найголовніше в компанії - це SQL Server та його бази даних. Є 10 баз даних, але лише 2 з них справді важливі. Перший - 8 Гб, переважно текстові дані та цифри. Другий - приблизно 300 ГБ із 16 ГБ на місяць, що містить PDF-файли та GIF-файли.

Для збереження поточної політики резервного копіювання зберігання складається з однієї повної резервної копії на тиждень та 6 диференціалів. Я думаю, що це близько 350 Гб на тиждень, 1,4 ТБ на місяць.

Прочитавши статті про безшумну корупцію даних, я вирішив спробувати ZFS з виданням Nexenta Community.

Моє запитання: чи добре ZFS з дедуплікацією для зберігання файлів резервної копії в умовах надійності чи я повинен думати про якусь резервну копію стрічки чи щось інше?

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

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

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

Тож моя відповідь "так", це добре, але я б пішов на обидва варіанти, якщо можете.

(припускаючи, що ви маєте на увазі використання дедупу в ZFS порівняно з вашим програмним забезпеченням для резервного копіювання)

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

Використання дедупу в ZFS надзвичайно інтенсивна оперативна пам'ять. Оскільки дедуплікація відбувається в режимі реального часу під час потоку / запису даних у пул пам’яті, існує таблиця, що підтримується в пам’яті, яка відстежує блоки даних. Це таблиця DDT . Якщо на сервері зберігання даних ZFS недостатньо оперативної пам’яті для розміщення цієї таблиці, продуктивність дуже постраждає. Nexenta попередить вас, коли таблиця зросте за певним порогом, але до цього часу вже пізно. Це може бути посилено за допомогою пристрою L2ARC (читати кеш-пам'ять), але багато ранніх прийнятих ZFS потрапили в цю пастку.

Подивитися:

ZFS - знищення подвоєного zvol або набору даних зупиняє сервер. Як відновитись?

ZFS - Вплив несправності кеш-пристрою L2ARC (Nexenta)

Коли я кажу, що потреба в оперативній пам’яті висока для використання дедупе, я б оцінив потреби RAM і L2ARC для набору даних, який ви описуєте, на 64 ГБ + ОЗУ та 200 ГБ + L2ARC. Це не незначні інвестиції. Зберігання безлічі системних файлів Windows та графічних документів, які не будуть прочитані, заповнить цей DDT дуже швидко. Виплата може бути не вартим інженерних робіт, які потрібно робити вперед.

Кращою ідеєю є використання стиснення на zpool, можливо, використання можливостей gzip для більш стисливих типів даних. Повторне копіювання не варто того, оскільки вам потрібно буде видалити подвійні дані (потрібно посилатись на DDT).

Крім того, як ви будете представляти сховище своєму програмному забезпеченню резервного копіювання? Який пакет резервного програмного забезпечення ви будете використовувати? У середовищах Windows я представляю ZFS як блокове зберігання в Backup Exec через iSCSI. Я ніколи не вважав, щоб функції ZFS CIFS були достатньо надійними, і віддав перевагу пристроям, що відформатовувались.

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

Альтернативою ОС є OpenIndiana, яка є настільки ж хорошою і щоразу отримує більш часті оновлення.

Інший варіант - встановити другий сервер ZFS з меншим (потенційно) пулом пам’яті з увімкненою компресією. Ви можете використовувати цей другий пристрій для статичного резервного копіювання. Таким чином, ви можете не обійтися кеш-пам'яттю читання, а також не потрібно нерозумно багато процесора / оперативної пам’яті, щоб обробити його.

Ми запускаємо налаштування так, як я працюю:

• Основний сервер зберігання даних OpenIndiana [ main ] з шести дисками 2 Тб у пулі RaidZ1 з трьох наборів дзеркальних пар. Це, скорочуючи наявний простір для зберігання даних, забезпечує швидкий і багаторазовий резервний накопичувач.
• Вторинний сервер зберігання [ резервного копіювання ] також працює OpenIndiana з аналогічною конфігурацією дисків, який служить виключно як резервний пристрій.
• main має скрипт, який запускається з роботи з кроном, який регулярно знімає / танк / [набір даних] протягом дня
• Кожного вечора виконується чергова робота з крон, яка підштовхує знімки дня через мережу до резервного копіювання . Після того, як буде виконано початкове синхронізація всіх ваших знімків (процедура, що займається лише один раз), покроковий характер знімків означає, що зміни висуваються на ваш резервний пристрій дуже швидко.

У мене є швидкий шлях про те, як встановити ZFS, надсилати / отримувати тут: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/