Hacker News Digest

Тег: #data-loss

Постов: 2

Fire destroys S. Korean government's cloud storage system, no backups available (koreajoongangdaily.joins.com) 🔥 Горячее 💬 Длинная дискуссия

Крупный пожар в дата-центре NIRS уничтожил облачную систему хранения данных правительства Австралии, включая информацию о налогах, бизнесе и судебных делах. Резервные копии отсутствовали, что делает восстановление практически невозможным. Это привело к параличу ключевых государственных служб и вызвало серьёзные опасения по поводу уязвимости критической инфраструктуры.

Инцидент подчёркивает системные риски централизованного хранения данных без надёжной стратегии резервного копирования. Последствия включают задержки в обработке документов, финансовые потери и потенциальные утечки конфиденциальной информации. Власти уже столкнулись с критикой за отсутствие планов аварийного восстановления.

by ksec • 05 октября 2025 г. в 17:20 • 1955 points

ОригиналHN

#cloud-storage#data-backup#data-loss#data-center#critical-infrastructure#it-infrastructure#disaster-recovery

Комментарии (872)

  • Пожар в дата-центре привёл к полной потере 858 ТБ данных государственного облачного хранилища Южной Кореи (G-Drive) из-за отсутствия внешних резервных копий.
  • Основной причиной утраты данных названа архитектура системы, которая, по заявлениям властей, не позволяла создавать внешние бэкапы из-за большого объёма и низкой производительности.
  • Участники обсуждают системные проблемы ИТ-инфраструктуры и культуры резервного копирования в Южной Корее, проводя параллели с инцидентом с Kakao.
  • Высказываются предположения о возможных скрытых причинах катастрофы, включая саботаж, коррупцию или умышленное уничтожение данных.
  • Отмечается человеческая трагедия: сообщается о самоубийстве старшего чиновника, курировавшего усилия по восстановлению.

Mind the encryptionroot: How to save your data when ZFS loses its mind (sambowman.tech)

Автор столкнулся с критической проблемой при шифровании пула ZFS: после переноса зашифрованных снапшотов с промежуточного пула sneakernet обратно на основной old данные оказались нерасшифровываемыми. Оказалось, что ZFS неявно создаёт зависимость от encryptionroot — исходного пула, где данные были впервые зашифрованы. В данном случае этим пулом был sneakernet, а не old, поэтому при попытке расшифровать данные на old система не смогла найти нужный ключ.

Ключевая деталь: ZFS передаёт метаданные о encryptionroot при операциях send/receive, даже если данные отправляются в raw-формате. Это привело к тому, что после удаления промежуточного пула sneakernet данные на old стали недоступны, так как система искала ключ от уже несуществующего источника. Автору удалось восстановить доступ, модифицируя исходный код ZFS для ручного создания bookmark и обновления метаданных, что подчёркивает важность понимания внутренней работы encryptionroot перед выполнением сложных операций с шифрованием.

by 6581 • 30 сентября 2025 г. в 20:58 • 126 points

ОригиналHN

#zfs#encryption#data-recovery#snapshots#metadata#data-loss#data-management#backup

Комментарии (41)

  • Пользователи обсуждают сложности и риски использования нативного шифрования ZFS, приводя примеры потери данных из-за ошибок в управлении ключами и снимками.
  • Поднимаются вопросы о сравнении ZFS с альтернативами (LUKS+mdadm, Storage Spaces), отмечая преимущества ZFS в эффективности сжатия и производительности, но критикуя его сложность и отсутствие дружелюбного интерфейса.
  • Обсуждается важность тестирования резервных копий и необходимость осторожности при использовании зашифрованных наборов данных, особенно при смене паролей или ключей.
  • Упоминаются случаи успешного использования ZFS в течение многих лет без потерь данных, но с оговорками о необходимости строгого следования документации.
  • Критикуется reliance на Stack Overflow и ИИ для решения сложных задач, поскольку это может привести к необратимым ошибкам из-за некорректных советов.