Як обробляти архівування даних? [зачинено]

Резервне копіювання - це одне, але довгострокове архівування - інше. Наприклад, вам може знадобитися зберігати електронні листи протягом 7 років або зберігати всі дані проекту на невизначений термін. Я зберігав архіви на стрічці, але потім у мене руйнуються стрічки (накопичувачі виривають стрічку). Отже ... напишіть на 2 стрічки, я чую, як ви говорите. Це те, що роблять інші? Чи є 2 (або більше) стрічок з однаковими даними для надмірності?

Але тоді інша проблема полягає в тому, що стрічки зазвичай не можуть читати різні виробники резервного програмного забезпечення. Наприклад, якщо ви переходите з Arcserve -> Backup Exec -> Commvault понад 10 років, вам потрібно буде зберегти всі 3 системи, щоб ви могли відновити старі дані. Так само і з обладнанням. Старі стрічки можуть бути не зашифровані. Можливо, це не сумісно з новою бібліотекою тощо. Отже, чи зберігаєте ви старий апаратний апарат і старе програмне забезпечення на випадок, якщо вам може знадобитися відновити 10-річний файл?

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

Будь-які думки?

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

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

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

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

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

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

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

• Архівуйте локальні стрічки, але не віддалені стрічки, і залиште стрічки всередині бібліотеки.

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

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

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

Хоча хвиля майбутнього, очевидно, є дисковим сховищем.

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

Дві установки EMC Centera (відображені в різних місцях). Коштує великих доларів, але це працює.

http://www.emc.com/products/family/emc-centera-family.htm

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

Які дані ви намагаєтесь створити резервну копію? Це все "випадкові" дані, такі як відео чи музика? Або це дані, які можуть піддаватися стисненню?

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

Через рік чи, можливо, через 2, ви можете почати відхиляти стрічки, якщо ці резервні копії більше не потрібні.

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

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

Моє рішення: виберіть лише одного постачальника з повним рішенням (програмне та апаратне забезпечення), якому ви довіряєте, зробимо все можливе, щоб запропонувати застарілу сумісність.

І, очевидно, отримайте дуже хороший ціновий контракт, враховуючи вашу вірність;)