Решение резервного копіювання для 10 ТБ даних та 3 сервери

Я шукаю резервне рішення для цього сценарію:

• 3 сервери (один поштовий сервер Linux, 2 сервери Windows)
• ~ 10 ТБ даних
• 2 туберкульозу, які знаходяться в щоденному вживанні
• кілька ГБ активності / зміни на день
• можливість відновлення даних з будь-якого моменту часу
• резервне копіювання виконується в реальній системі (міжнародний офіс)
• База даних MSSQL також потребує резервного копіювання
• Немає достатнього мережевого з'єднання для резервного копіювання даних поза сайтом
• Нескладний доступ (рідна файлова система) до захищених даних.

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

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

Як би ви встановили подібне резервне копіювання даних? Яке програмне забезпечення ви б рекомендували?

Перенесення дисків з дельтою на зовнішній сервер до дзеркального сервера - це варіант. Яке обладнання ви б використовували?

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

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

Одне, на що ви можете поглянути, - це Drobo pro , якщо ви завантажите один з них на 2-футових накопичувачах, ви можете отримати 16 тб. Я з нетерпінням чекаю, щоб дати одному з них піти (коли я отримаю кошти :)), але я маю чудові відгуки про них і про те, що за кілька років вниз по дорозі вам потрібно оновити, ви просто візьміть кілька дисків і покладіть новий жорсткий диск, який має ще більше смішного простору.

Вам, мабуть, буде найкраще, якщо ви інвестуєте в перевірене рішення.

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

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

Ви також повинні переконатися, що все, з чого починається ваш резервний сервер, продукт підтримує розширювану пам’ять. Таким чином, ви можете почати з 10 ТБ і додавати більше дисків у процесі роботи.

З декількома комп'ютерами також буде сприятливим клієнт без резервного копіювання. Так що ви можете створити резервну копію всієї локальної мережі з одного резервного клієнта. Деякі продукти також включають віртуальний комп'ютер на основі розташування FTP / SFTP / FTPS. Таким чином, ви можете мати резервного клієнта у Windows та створити резервну копію всіх локальних машин + Linux-машини з одного інтерфейсу.

Я б не використовував підхід, заснований на жодному з 1) Поступових резервних копій та 2) диференціальних резервних копій. За допомогою інкрементальних резервних копій ви хочете зробити з часом ще одну повну резервну копію, або в час відновлення вам доведеться відновити занадто багато резервних копій. За допомогою диференціальних резервних копій, ви захочете зробити ще одну повну резервну копію, інакше ваша диференціальна резервна копія стане занадто великою. У вашому випадку вам доведеться повторно надіслати 10TB. Це не прийнятно.

Переконайтеся, що ви завантажуєте дані на сервер резервного копіювання, що дані НІКОЛИ не потребуватимуть нової повторної передачі, якщо вони не змінені.

Переконайтеся, що вам НЕ ПОТРІБНО відновити повне резервне копіювання, і що ви можете відновити лише підмножину того, що ви створили резервну копію, і що ви можете вибрати із резервних копій такі, які були в день, коли ви відновлювали.

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

Не забудьте обрати рішення, в яке вбудовані резервні копії MS SQL та обмінні резервні копії, і вам не потрібно повторно переносити все щоразу, коли ви створюєте їх резервні копії. Він повинен підтримувати гарячі резервні копії цих елементів.

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

Дивлячись на сценарій, найкраще рішення для резервного копіювання може дати "faubackup", перегляньте цю сторінку http://faubackup.sourceforge.net/ .

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

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

Виконання 'faubackup srcdir destdir' трохи схоже на 'cp -a srcdir destdir /' date ''. Тобто він скопіює все з srcdir у підкаталог destdir. Цей каталог названий за часом резервного копіювання (формат "РРРР-ММ-DD @ hh: mm: ss"). Усі назви файлів, дозволів, вмісту будуть збережені. Він може впоратися з м'якими, жорсткими посиланнями та з отворами у файлах.

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