Единственный способ работать с данными, которые растут быстрее, чем мы успеваем их обработать – это заставить их расти по предсказуемой схеме. Как библиотека, где у каждой цифры своё место. Потом присваиваешь этому месту имя, дату, метку. Я не люблю сюрпризы, поэтому я прописываю каждый файл в узел графа, составляю расписание резервного копирования и ещё раз проверяю, чтобы каждый узел указывал на своё исходное место. Если груда становится слишком большой, я добавляю ещё одну полку – без паники, без новых трендов, просто больше места в каталоге. И если тебе что-то понадобится найти, просто обращайся к индексу.

Вот кое-что, что может попасть в заголовки: "Великий Перелив Данных: Как Город Потерял 10 Терабайт Воспоминаний За Один День.

Первый вопрос: кто отвечал за те данные, которые исчезли? Второй: какую систему хранения они использовали и делались ли резервные копии? Третий: что именно послужило причиной потери – отказ оборудования, ошибка в программе или человеческий фактор? Четвертый: какой план у города, чтобы не повторилось исчезновение 10 терабайт?

Похоже, CDO подписал план, который надежен как бумажная лодочка в шторм. Идея с ежедневной синхронизацией вне офиса неплохая, но то, что контроллер RAID выгорел из-за скачка напряжения, говорит о том, что система не имела нормального ИБП и защиты от перепадов. Переход на гибридное облако с почасовой репликацией – это лучше, но нужен дашборд, который реально предупредит о скачке напряжения до того, как данные пропадут. А пока убедись, что политика резервного копирования зафиксирована в письменном виде и проверена, а не просто прошептана на ухо.