Економічно довгострокове архівування даних про відео та зображення? ~ 50 ТБ

У моїй лабораторії знаходиться процес створення невеликого сервера, на якому зберігаються дані (в основному дані про відео та зображення, а також кілька документів) для проекту, над яким над тим, що над нами працює група. Історично, після закінчення дослідницького проекту, дані випадково закінчуються архівуванням на одному жорсткому диску або великій купі DVD-дисків (або компакт-дисків за старих часів), та / або деякі відеозаписи потрапляли на касети Sony DV або навіть VHS-стрічки (ця лабораторія була активною з початку 90-х), АБО суміш усіх перерахованих вище ...

Питання: Який найкращий спосіб для (1) консолідації ВСІХ в одному форматі І носії інформації та (2) який найкращий носій для довготривалого архівування таких даних для дуже випадкового доступу (скажімо, 30+ років?)? На жаль, у нас немає бюджету на рівні підприємства (ми просто ~ 10 людей в лабораторії), тому не можемо робити речі, які коштують сотні тисяч доларів.

Спасибі!

PS Враховуючи, що наші старі відео та зображення мають меншу роздільну здатність, але останніх величезна кількість, я думаю, ми говоримо про 30 ~ 40 ТБ для дійсно старих даних, ще 10 ~ 20 ТБ для останніх даних, а потім щорічно додавання близько 5 ТБ .

На жаль, для вас немає найкращого способу. 30-річне архівування цифрових носіїв є дуже важкою проблемою і вимагає звичайних інвестицій. Єдиними форматами, які гарантовано читаються через 30 років, є ASCII та UTF8, які не є відеоформатами. Змінюються формати зберігання, 8 стрічкових котушок до котушок, які ми використовували 30 років тому, майже неможливо прочитати в наші дні, хоча дані все ще є на стрічці (є цікава історія про відновлення NASA 40-річного стрічкового накопичувача NASA щоб потрапити на кілька щойно відновлених / виявлених стрічок даних Apollo). Ваша найкраща ставка - взяти на себе зобов’язання періодично, я б сказав, кожні 5 років, оцінювати ваше архівне середовище з достатнім бюджетом, щоб перетворити старі формати в новіші формати.

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

• Встановіть своє архівне вікно на 5 років.
  • На найближчу перспективу має бути достатньо масиву для зберігання (
    • великий і повільний 50TB диск може бути за $ 70 000, можливо, і менше.
    • LTO5 стрічковий накопичувач та 50 стрічок (що коштує понад 50 ТБ) можна придбати за менше 15 доларів.
• У якому форматі ви будете зберігати своє відео, залежить від вас.
• Почніть шукати та перетворювати всі ваші старі речі в цю нову пам’ять.
• Наприкінці 5 років зробіть ще одну повну оцінку свого архівного середовища.
  • Які формати ви використовуєте?
  • Які новіші формати?
  • Які кодеки здаються тупиковими, а які носії ви зберігаєте таким чином?
  • Вирішіть, як ви збираєтеся перейти на новіші способи зберігання (формати даних, диск / касета / щось інше) та витрачайте належним чином.
• Повторіть 6 разів.

Це повинно отримати вас до 30 років.

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

Вам потрібно створити 5 основних функцій;

• стандартизована політика щодо вмісту та каталогів - я знаю, що ви хочете зберігати все в одному форматі, але ви дійсно повинні розглянути два - PDF для зображень і H.264 для відео - обидва формати довгострокової підтримки з багатоплатформовим кодом, які майже Безумовно, підтримка тієї чи іншої сторони протягом 25-50 років у їхньому нинішньому вигляді просто завдяки існуючому використанню в усьому світі.
• каталог або CMS для індексації та публікації вмісту.
• система "введення вмісту" - це займе весь ваш медіа, пакувати, кодувати, зберігати та оновлювати каталог для кожного нового вмісту. Вам також знадобиться ручна або автоматизована перевірка якості вмісту.
• первинний сховище вмісту - це матиме два основні блоки зберігання; один невеликий для зберігання початкового вмісту під час його перекодування / перевірки та набагато більший блок для вмісту вмісту "біля". Це одне з єдиних дійсних застосувань для RAID 6, з яким я натрапив, але спробуйте використовувати корпоративні диски якості, які мають "робочий цикл" 24x365 тут.
• система довгострокового резервного копіювання - саме тут будуть витрачені реальні гроші, вам потрібно вибрати постачальника, який пропонує справді довгострокові можливості резервного копіювання. Якби я робив це зараз, я все-таки переходив би стрічку на диск виключно з приводу довголіття даних, можливо, IBM, оскільки у них є великий досвід у цій галузі. Вам також потрібно врахувати, що вам також потрібно регулярно відновлювати стрічки та перевіряти дані, тобто третій блок зберігання повинен бути принаймні таким же великим, як найбільша у вас стрічка - і системи, звичайно, теж перевіряти. Крім того, вам потрібно буде забезпечити, що програмне забезпечення для резервного копіювання, яке ви використовуєте, також буде довгий час, щось на зразок TAR на * nix, швидше за все, буде деякий час, але це може не функціонально дати вам те, що ви хочете так переконайтеся, що ваш постачальник стрічки не помітить цього.

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

Удачі.

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

http://www.digitalpreservation.gov/formats/index.shtml

Ви також можете розглянути можливість створення дешевого масиву ZFS для білого ящика. Можливо, ви могли б зробити щось, що відповідає вашим потребам за ціною менше 10 000 доларів. У міру відмирання накопичувачів замініть їх на більші, і тому ваш накопичувач зростає в міру створення даних. Це, ймовірно, триватиме вас досить довго, і ви можете замінити його пристроєм більшої ємності, коли він постаріє. Перевага полягає в тому, що ваші дані є в Інтернеті (і тому до нього можна отримати доступ за необхідності) і відносно добре захищені від бітрот, серйозна проблема, коли у вас є стільки даних.

Тут було зібрано гідний варіант складання:

http://www.zfsbuild.com/

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

Приклад:

• Як ви збираєтеся мати справу з перетворенням аналогових / різних форматів цифрових стрічок в цифрові носії, які можна зберігати на якомусь цифровому сховищі?
• Як ви збираєтесь керувати вмістом та пов'язаними з ними метаданими? Зберігання просте - ви можете поставити все на стрічку LTO і зберігати його в старому соляному шахті, але ви б не мали доступу до даних.
• Ви знову вигадуєте колесо? Якщо ви в університеті, чи вже є рішення щодо управління вмістом, які доступні в центрі? Або якщо вам потрібно придбати / побудувати власне управління контентом, чи є централізована інфраструктура, для якої ви можете придбати частину? (Стрічка, Об'єкт зберігання, SAN)
• Які реальні вимоги бізнесу? Що ви насправді хочете зберегти і чому? Часто, коли ви дійсно занурюєтесь в суть справи, реальні вимоги щодо довготривалого утримання фактично застосовуються лише до невеликого підмножини даних.

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

Далі йде мова про аудіо, але те саме стосується:

Ви можете конвертувати будь-який аудіо формат у Ogg Vorbis. Однак перетворення з одного формату втрати, як MP3, в інший формат втрат, як Vorbis, як правило, погана ідея. Як кодери MP3, так і Vorbis досягають високих коефіцієнтів стиснення, викидаючи частини аудіосигналу, які ви, мабуть, не почуєте. Однак кодеки MP3 і Vorbis дуже різні, тому кожен з них викине різні частини аудіо, хоча, безумовно, є певне накладення. Перетворення MP3 у Vorbis включає в себе декодування MP3-файлу назад у нестисненому форматі, наприклад WAV, та його повторне стиснення за допомогою кодера Ogg Vorbis. У декодованому MP3-файлі будуть відсутні частини оригінального звуку, які MP3-кодер вирішив відмовити. Потім кодер Ogg Vorbis відкидає інші аудіо компоненти при стисненні даних. У кращому випадку, в результаті вийде файл Ogg, який звучить так само, як і ваш оригінальний MP3, але найімовірніше, що отриманий файл буде звучати гірше, ніж ваш оригінальний MP3. Ні в якому разі не ви отримаєте файл, який звучить краще, ніж оригінальний MP3.

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

(Якщо ви повинні абсолютно конвертувати з MP3 в Ogg, на Freshmeat доступні кілька скриптів перетворення.)

http://www.vorbis.com/faq/#transcode

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

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

Таким чином Amazon повинен турбуватися про фактичне зберігання даних, і, якщо не буде комп'ютерів, які могли б компілювати C / C ++ за 30 років, ви зможете отримати інформацію ...