Чи все-таки мені потрібна резервна копія, якщо у мене є система резервного зберігання з можливостями відката?


32

Нещодавно моя організація придбала систему зберігання. Він має 1,5Petabyte, з RAID6, і є онлайн-синхронізоване дзеркало в іншому фізичному місці.

Система дозволяє відкати / відновлення файлів, за замовчуванням дозволяє до 30 днів, але це може бути збільшено.

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

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

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

Чи нам це справді потрібно? Я щось пропускаю? Чи я просто думаю традиційним способом і надто ревно?


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

4
Однозначно пов'язаний, але, можливо, не відвертий дублікат через географічну поділ та можливість відкату знімків: Чому RAID не є резервною копією?
CVn

Поки ви також видаляєте клавішу "видалити" з кожної клавіатури на своєму місці, ви золото ;-)
Том Ньютон

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

7
Чи охоплює ваша можливість "відкату" також зміни обсягів? Наприклад, чи вдасться відновити, якщо хтось видалить усі обсяги?
vhu

Відповіді:


40

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

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


3
Або оскільки обидва сховища, ймовірно, використовують одну і ту ж ОС, програмна помилка може знищити дані. Неможливо, помилка адміністратора є більш імовірною, але можливою.
Sunzi

8
Правда. Мета полягає в тому, що ніхто не зможе керувати автоматизованими знімками. Це повинно дати рівень стійкості до помилок. Звичайно, можна також помилково видалити резервну копію.
nsn

2
@nsn є багато інших поправок, таких як помилки в програмному забезпеченні пристрою або помилки у ваших сценаріях управління. Без резервного копіювання десь ви довіряєте свою роботу продавцеві ... Чи готові ви це робити? Також кількісно визначте шкоду в разі втрати. Можливо, відповідь залежить від того, наскільки цінні дані. Чи компанія без нього пішла?
usr

2
@ nsn > Звичайно, можна також помилково видалити резервну копію. < - так, але це стає значно складніше, коли резервна копія зроблена в автономному режимі і розміщена, наприклад, у захищеному, зовнішньому сховищі.
Роб Моїр

7

30-денний відкат - це чудова можливість, але що робити, якщо "критично важливий файл-xyz" став пошкодженим / пошкодженим, і це не було виявлено до 31+ днів? Ця ситуація є різницею між резервними та архівними розкладами, але у вашому описі останній не згадується. Архівні системи, як правило, зберігаються на магнітофонній стрічці. Також немає інформації про те, чи є підприємство таким, що має нормативні чи інші вимоги щодо зберігання даних довше 30 днів, що часто буває.

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


3
Так, правда. 30 - це лише за замовчуванням, яким ми можемо встановити інші значення. У будь-якому випадку, офлайнове зберігання також коштує грошей і не зберігається назавжди Завжди буде день n + 1
nsn

2
Мені подобається тривати 30 днів, плюс щомісяця за останній рік, плюс щорічно. У мене було декілька файлів (важливих і старих), і вони не виявляються протягом певного періоду. Щорічні резервні копії можуть врятувати життя.
Брайан Кноблаух

@BrianKnoblauch: Так, така схема є гарною ідеєю як для онлайн-знімків, так і для автономних резервних копій.
Бен Войгт

6

Добре мати географічно відокремлені машини, які мають дані.

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

Отже, це зводиться до того, наскільки важливими / цінними є ці дані? Що зробить організація, якщо вона закінчиться?


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

2
Це йде назавжди. Кожен раз, коли ви додаєте рівень надмірності, ви завжди можете очікувати, що він вийде з ладу (або географічним, або просто диском). Якщо у вас n зайвих дисків, ви завжди можете запитати "що робити, якщо n + 1 розбивається". Також у вашій серверній кімнаті та в резервній кімнаті може бути пожежа. Внутрішні робочі місця також можуть атакувати обох. Немає 100% безпечних систем. Тут справа в тому, щоб знати, чи така установка може бути еквівалентною "традиційному" серверу + резервне копіювання
nsn

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

@Nick, я думаю, у вас є дуже вагомий коментар. Я би зробив це відповіддю.
nsn

4

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

Щоб зібрати (вишневий) деякі думки в інших відповідях та коментарях, ви можете піти далеко вниз "добре, що технологія X не охоплює сценарій стихійного лиха Y, тому це не резервне копіювання", і в якийсь момент вам потрібно вирішити, що для вас розумно, і, здається, саме тому ви питаєте. Моє відчуття щодо цього, і я думаю, що почуття багатьох коментаторів полягає в тому, що ваша резервна копія повинна існувати на окремій технологічній інфраструктурі, ніж ваші дані, що використовуються, так що збої, аварії та шкідливі дії не можуть розповсюджуватися або мати набагато вища перешкода для перетину. Прикладом, наведеним у коментарях, є те, що хтось видаляє томи, що, на мій погляд, є дійсним сценарієм, який не є простою. Але додатково - реальний приклад з моєї роботи. В університеті, в якому я працюю (але, на щастя, не ставте " t керувати цією інфраструктурою) має серйозну інфраструктуру віртуалізації з високою доступністю, яка підтримує безліч об'єктів кампусу. Він розміщений на кількох сайтах, але все працює на платформі одного постачальника. Одного дня з'явився незрозумілий помилка, який спричинив каскад помилок, який спочатку зняв єдиний сервер, потім, коли навантаження змістилося, він вийняв решту цього сайту, а потім, коли завантаження знову змістилося, він вийняв інші сайти, що розміщують хостинг та інфраструктура. (Я вважаю, що вони вирішили це питання з того часу). Дані в цьому випадку не втрачаються, але можливо уявити сценарій, що включає ваші дані там, де вони були. Одного дня з'явився незрозумілий помилка, який спричинив каскад помилок, який спочатку зняв єдиний сервер, потім, коли навантаження змістилося, він вийняв решту цього сайту, а потім, коли завантаження знову змістилося, він вийняв інші сайти, що розміщують хостинг та інфраструктура. (Я вважаю, що вони вирішили це питання з того часу). Дані в цьому випадку не втрачаються, але можливо уявити сценарій, що включає ваші дані там, де вони були. Одного дня з'явився незрозумілий помилка, який спричинив каскад помилок, який спочатку зняв єдиний сервер, потім, коли навантаження змістилося, він вийняв решту цього сайту, а потім, коли завантаження знову змістилося, він вийняв інші сайти, що розміщують хостинг та інфраструктура. (Я вважаю, що вони вирішили це питання з того часу). Дані в цьому випадку не втрачаються, але можливо уявити сценарій, що включає ваші дані там, де вони були.

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

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


1

Припущення: система зберігання буде використовуватися багатьма програмами.

Я вважаю, що ви зробите набагато краще з окремою системою резервного копіювання.

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

АЛЕ:

Я вважаю за краще, щоб політики відновлення були на основі додатків / даних, а не на сховищі, оскільки:

  1. програми мають різні вимоги, пов’язані з відновленням і прийнятною втратою даних (деякі з них накладаються різними правилами: носії лише для читання, шифрування, зберігання останніх X років тощо),
  2. деякі програми мають (дуже) хороші інструменти для резервного копіювання та відновлення (oracle, mssql), вбудовані і рекомендують спосіб зробити частину резервного копіювання / відновлення (як Oracle DBA, я вважаю за краще, і я буду робити всі резервні копії, пов'язані з Oracle, з rman).
  3. зростання, ваше використання простору може зростати набагато швидше, ніж ви очікуєте, тепер ця система може вмістити 30 днів відката даних, це не гарантується в майбутньому
  4. дешевше, вартість використання більших стрічок для розміщення резервних копій / відновлення після декількох років зростання буде меншою, ніж вартість придбання нових, більших дисків, щоб дотримуватися того ж вікна відкату, що і зараз
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.