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

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

Є лише три сервери, на які я буду створювати резервну копію, загальна кількість даних - приблизно 200 Гбіт. Я буду робити щотижневі повні резервні копії по суботах, а потім диференційовані резервні копії з понеділка по п’ятницю. Також буде повністю резервне копіювання на кінець місяця, яке зберігатиметься поза сайтом для цілей DR.

Обладнання, яке використовується: -8 резервне накопичувальне гніздо стрічки - стрічки LTO2 -Backup Exec 12.5 з агентами Exchange і SQL

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

Отже, моє запитання таке: скільки стрічок я повинен використовувати в кожному наборі? Чи потрібно використовувати вісім, оскільки резервний диск приймає до восьми стрічок? Чи його скинуть, якщо я покладу менше?

По-друге, оскільки резервне копіювання різного тижня щовечора буде, мабуть, приблизно приблизно 5 Гбіт або близько того, чи потрібно мені вставляти п'ять стрічок LTO2 (які вміщують до 400 Гбіт) у медіафон, по одній стрічці на кожну ніч? Або одного достатнього, оскільки теоретично він міг би проводити багатотижневі відмінності?

Я не розумію, що якщо BE обирає нову стрічку на кожен день, або якщо вона просто продовжуватиме додавати її до тієї самої стрічки, поки вона не заповниться, а потім перейде на наступну.

Можливо, простіше задати питання: якщо б у вас було обладнання для резервного копіювання та сервери для резервного копіювання, перелічені вище, яким би був ваш дизайн резервного копіювання?

Велике дякую....

Я б дуже рекомендував книгу В. Кертіса Престона "Резервне копіювання та відновлення" (книга O'Reilly)

http://oreilly.com/catalog/9780596102463/

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

На мою думку, Backup & Recovery виконує досить непогану роботу, розмовляючи про сильні та слабкі сторони різних варіантів, які ви можете (або не можете) вибрати.

Отже, саме тут я б почав першим.

Минув час, коли я це налаштував, і я вдома, тому йду з пам’яті.

У нашому випадку у нас є привід LTO-3, повна резервна копія вміщається на дві стрічки, і всі відмінності на тиждень поміщаються на одній. Тому щотижня ми маємо набір стрічок, що складається з двох стрічок для повної та третьої стрічки для наступних 5 різниць. Ми зберігаємо ці комплекти протягом 5 тижнів, у нас є один виїзд і 4 на місці.

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

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

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

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

Ви сказали, що LTO-2 та 200 Гб, тому на пару ваших магнітофонів має бути повний, 3 - у найгіршому. Отже, у вас може бути одразу 6 стрічок для повних і 2 для різниць у навантажувачі, то щотижня вам потрібно буде витягнути один набір цілісних і вставити інший. Якщо ваші резервні копії вміщуються на 2 стрічках, у вас може бути 3 набори повноцінних підказок, і вам потрібно міняти місцями лише кожні 2 тижні.

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

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

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

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

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

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

По-друге: ви повинні бути обережними щодо різниці між "диференціалом" та "поступовим" резервним копієм. "Диференціальне" резервне копіювання - це всі відмінності між "зараз" та опорною точкою, як правило, останньою повною резервною копією. Отже, якщо ваша дельта становить близько 5 ГБ в день, то перший день вона буде 5 ГБ, друга потенційно 10 ГБ і т.д., і т. Д. "Інкрементальна" резервна копія - це різниці між "зараз" і останнім запуском резервного копіювання, що може бути поступовий сам по собі. Таким чином, ваша перша дельта буде 5 ГБ, друга 5 ГБ і т.д., і т.д.

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

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

Що стосується ваших ротацій - якщо все, що вам потрібно, - це два тижні на місці, то ваш шаблон, мабуть, нормальний. Однак ми завжди використовуємо повніше обертання.

• Перша п'ятниця місяця: місячне резервне копіювання. Відправляється за межами місця на один (або два) роки (залежно від замовника).
• Друга по четверту (або п'яту) п’ятницю: тиждень від А до C (або D). Їх відправляють за межі міста та повертаються через місяць.
• З неділі по четвер: додаткове або диференційоване резервне копіювання, залежно від вимог та можливостей замовника. Вони живуть два тижні і залишаються на місці.

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

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

Якщо ви нічого більше не читаєте, прочитайте "Backups Suck" від M.Janke тут: http://www.standalone-sysadmin.com/blog/2009/02/backups-suck/

Я погоджуюся, що вам потрібно більше ніж 2 резервні набори. Я вважаю, що 4 є розумним числом (тож у вас є стрічки приблизно на кілька місяців, на які потрібно повернутися, якщо щось переходить у сірий). Під час налаштування резервних копій у Backup Exec у вас є вибір або додати дані, або перезаписати дані. У вас також є вибір, що робити, якщо ви сказали додавати, але стрічка заповнена. Крім того, ви можете керувати налаштуваннями захисту від перезапису на вашому медіа-пулі, щоб запобігти випадковому перезаписуванню стрічки, яку щойно використали. Одним підказом я схиляюсь до того, що стрічки не завжди змінюються, коли їм належить (тому що хтось хворий, або у відпустці, або на відпочинку), тому, якщо можливо, я намагаюся мати два набори стрічок у привід. Ті на цей тиждень, а на наступний тиждень. Так що у вас є цілий тиждень, щоб витягнути поточні резервні копії, перш ніж все зіпсується. Також слід поглянути, чи підходить 6 ночей різниці на одній стрічці. Якщо їх немає, але ви можете врахувати додаткові прибутки на 6 ночей. Це збільшує час, необхідний для повного відновлення (особливо до кінця тижня), але це може бути варте того, якщо зменшить кількість необхідних стрічок.

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

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

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

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

Сказавши це, ось моя рекомендація:

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