Hacker News Digest

Судя по данным, жесткие диски действительно стали надежнее. Исследование Backblaze, ведущего поставщика облачных сервисов, показывает, что современные диски служат дольше и стабильнее работают в течение жизненного цикла.

Первоначальная модель "ванны" (bathtub curve) предполагала три фазы: ранние отказы, стабильный период и рост отказов по мере износа. Но данные Backblaze за 13 лет показывают, что современные диски начинают с минимальным числом ранних отказов, затем работают годами без сбоев, и только позже начинают увеличивать частоту отказов. Это больше похоже на пологий склон, чем на ванну.

В частности, средний возраст дисков в пуле Backblaze увеличился с 6-8 месяцев в 2013 году до 6-7 лет в 2024. При этом годовая норма отказов снизилась с 6,39% в 2014 году до 1,17% в 2024. Это демонстрирует значительное улучшение надежности, даже с учетом роста объема данных и изменения состава пула дисков.

Основные выводы:

• Современные диски имеют минимальные ранние отказы, что указывает на улучшенный контроль качества.
• Период стабильной работы удлинился, иногда до 8 лет и более.
• Даже при увеличении срока службы, годовая норма отказов снижается, что подтверждает улучшение надежности.

Это подтверждается данными Backblaze, которые включают миллионы дней работы диска. Тенденция ясна: диски не просто служат дольше; они стабильнее на протяжении всего срока службы.

• Обсуждение охватывает широкий спектр тем: от анализа отказов жестких дисков и их долговечности до стратегий резервного копирования и восстановления данных, включая использование ZFS, RAID и облачных хранилищ.
• Участники обмениваются личным опытом и мнениями о надежности различных производителей и моделей HDD и SSD, а также обсуждают влияние условий эксплуатации на срок службы накопителей.
• Обсуждаются практические аспекты, такие как стоимость, энергопотребление и плотность хранения данных, а также влияние технологических усовершенствований на эти параметры.
• Участники также затрагивают тему долгосрочного хранения данных, включая использование оптических носителей, магнитной ленты и облачных сервисов, и обсуждают их достоинства и недостатки.
• В обсуждении также поднимается вопрос о том, какие факторы влияют на отказы накопителей и какие меры можно предпринять для обеспечения целостности данных, включая использование корректных файловых систем и регулярное тестирование состояния накопителей.

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

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

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

Приложение Apple Photos иногда повреждает изображения при импорте с камеры. Я хотел поделиться этим, так как другие пользователи тоже сталкивались с проблемой, но большинство сдались, не разобравшись так глубоко, как я.

Я снимаю на камеру OM System OM-1 в формате RAW + JPEG и раньше использовал опцию «Удалить после импорта», чтобы очистить карту памяти. Это оказалось ошибкой. Проблема стала очевидной после съёмки на свадьбе: около 30% фотографий были безвозвратно испорчены — иногда JPEG, иногда RAW, иногда оба файла.

Чтобы исключить аппаратные причины, я последовательно менял всё оборудование: кабели, карту памяти, перешёл только на RAW, купил новый ноутбук и даже новую камеру OM-1 MKII. Но проблема не исчезла. Позже я обнаружил, что файлы на карте были целыми до импорта, а corruption происходил случайным образом в самом приложении Photos.

Сравнение повреждённого и исходного файлов показало одинаковый размер, но разные контрольные суммы:

md5sum P7110136-from-camera.ORF Exports/P7110136.ORF 
17ce895fd809a43bad1fe8832c811848  P7110136-from-camera.ORF
828a33005f6b71aea16d9c2f2991a997  Exports/P7110136.ORF

Теперь я отказался от автоматического удаления и вручную проверяю все фото после импорта, прежде чем форматировать карту. Это трудоёмко, но надёжно. Возможно, проблема связана с конкретными камерами OM System, но я не планирую дальше её исследовать.

• Обнаружена редкая ошибка в Apple Photos, приводящая к недетерминированному повреждению файлов при импорте, вероятно, из-за проблем с параллелизмом в конвейере обработки.
• Пользователи сообщают о различных случаях коррупции изображений: от зеленых пикселей до полной порчи файлов и потери целых архивов, в том числе в iCloud.
• Многие критикуют рабочий процесс с автоматическим удалением файлов после импорта и рекомендуют всегда сохранять оригиналы на картах памяти или делать резервные копии перед импортом.
• В качестве альтернативы предлагается использовать другие инструменты для импорта (например, Image Capture, Digikam, Olympus Workspace) или полностью отказаться от экосистемных решений в пользу локального хранения и самохостинга.
• Высказывается общая обеспокоенность снижением качества программного обеспечения Apple и недостаточным вниманием к тестированию и сохранности данных пользователей.
• Некоторые пользователи предполагают, что проблема может быть связана с конкретными камерами (OM System) или SD-картами, а не только с ПО Apple.
• Рекомендуется документировать версии ПО с ошибкой и избегать хранения критически важных данных исключительно в проприетарных системах без независимых бэкапов.

Что это
Приложение для macOS, которое автоматически сохраняет «точки восстановления» проектов Claude Code. Если что-то пошло не так — один клик и вы вернулись к рабочей версии.

Как работает

1. Выберите папку проекта.
2. Продолжайте кодить — изменения отслеживаются сами.
3. При завершении задачи создаётся контрольная точка.
4. В любой момент можно откатиться или посмотреть diff.

Основное

• Авто-обнаружение изменений — без настройки.
• Визуальный diff — видно, что добавлено, удалено, изменено.
• Полное резервное копирование — каждая точка = весь проект.
• MCP-интеграция — Claude Desktop сам создаёт точки при task completed.
• macOS 13.5+, бесплатно.

Команды MCP

update_task_status("task", "completed")  # контрольная точка
restore_checkpoint("id")                 # откат

Скачать
Mac App Store

• Пользователи спорят, нужен ли отдельный инструмент для «чекпойнтов» в Claude Code: одни советуют Jujutsu или обычный git, другие хотят встроенную функцию «откатить и код, и контекст».
• Разработчик подтверждает, что под капотом используется git в скрытой папке .claudecheckpoints, чтобы не пачкать основной репозиторий.
• Некоторые считают задачу надуманной: достаточно добавить в CLAUDE.md правило «делай git-commit после каждого изменения» или пользоваться Cursor/Aider.
• Критика UI и стабильности: зависания, лишние кнопки, «vibe-coded» дизайн.
• Общий вывод: пока Claude Code не добавит родные чекпойнты, такие сторонние обёртки имеют смысл, но рискуют стать ненужными после одного обновления самого Claude.

git-annex — управляет большими файлами в git, не храня их содержимое. Поддерживает синхронизацию, резервное копирование, шифрование и работу офлайн.

Для любителей командной строки — полный функционал; для остальных — git-annex assistant превращает всё в простую синхронизацию папок.

Быстрый старт

• установка
• обзор
• советы

Ключевые темы

• как работает
• специальные remotes
• сценарии
• предпочтения содержимого

Примеры

Архиватор Боб хранит данные на множестве отключённых дисков. git-annex показывает, где лежит нужный файл, и позволяет безопасно переупорядочивать дерево. Ночью cron-команды добавляют новое и отслеживают дубликаты.

Кочевница Алиса синхронизирует ноутбук, USB-диск, сервер и облако как git-удалённые репозитории. В самолёте или кафе она выбирает, что скачать, что удалить, а при подключении всё автоматически сливается обратно.

• git-annex отлично подходит для персонального управления большими файлами на множестве носителей, включая офлайн-диски, и гарантирует контроль целостности.
• Пользователи жалуются на сложность освоения, «тяжёлый» Haskell-стек зависимостей и проблемы с плагинами облачных провайдеров.
• В много-юзерных репозиториях «магические» ветви git-annex плохо масштабируются; для коллаборации чаще выбирают Git-LFS.
• Крупные репо (десятки ТБ и сотни тысяч файлов) замедляются до минут ожидания на каждую операцию, особенно при дефолтных «параноидальных» проверках.
• Git-annex и LFS решают разные задачи: первый — распределённое резервное хранение, второй — версионирование больших файлов в dev-репозиториях.