Миф: SSD не нужно бэкапить, они не ломаются

MAATRIX

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

Откуда взялось рациональное зерно мифа

У классического HDD есть механика: шпиндель крутит пластины на скорости 5400-7200 об/мин, магнитная головка висит над поверхностью на воздушной подушке в единицы нанометров. Отсюда — головка может ударить о пластину при тряске (head crash) и повредить поверхность необратимо, подшипник шпинделя изнашивается на больших пробегах, головка может залипнуть на парковочной зоне при долгом простое.

SSD ничего из этого не имеет: движущихся частей нет, данные хранятся в ячейках флеш-памяти NAND, обращение к ним электрическое, а не механическое. SSD действительно ощутимо устойчивее к ударам и вибрации — сервер с SSD, который уронили при монтаже в стойку, с большей вероятностью останется живым, чем тот же случай с HDD. Это реальное инженерное преимущество. Проблема в том, что из него делают ложный вывод: «раз механики нет — значит, и отказов почти нет».

Как SSD отказывает на самом деле

SSD не бессмертен, у него просто другой набор точек отказа.

Износ ячеек флеш-памяти (write endurance). Каждая ячейка NAND выдерживает ограниченное число циклов записи-стирания, после чего перестаёт надёжно держать заряд. Процесс постепенный и предсказуемый: контроллер отслеживает деградацию через wear leveling и отражает её в SMART-атрибутах вроде Media_Wearout_Indicator. Подробно про сам механизм и метрики TBW/DWPD — в статье как SSD умирает медленно: wear leveling простыми словами.

Внезапный отказ контроллера — ключевое отличие от HDD. У HDD, доживающего свой ресурс, почти всегда есть предвестники: растёт число переназначенных секторов, увеличивается время доступа, SMART начинает ругаться заранее — есть окно в дни или недели на реакцию. У SSD контроллер — отдельный чип, который управляет картой соответствия логических и физических адресов (FTL) и обработкой ошибок. Если в нём происходит аппаратный сбой или теряется карта адресов, диск нередко отказывает целиком и сразу: работал — и в следующую секунду не определяется вообще, без предварительной деградации. SMART в этом сценарии часто не успевает предупредить, потому что сам контроллер, формирующий SMART, и есть точка отказа.

Проблемы прошивки. Баг в firmware — известная категория отказов SSD: после определённой наработки или последовательности операций диск переставал определяться на конкретных партиях у разных производителей. Обычно закрывается обновлением прошивки, но узнаёте вы об этом постфактум.

Скачки питания. Электроника контроллера чувствительна к нестабильному напряжению так же, как любая плата. Резкий скачок может повредить контроллер безвозвратно, а отключение питания в момент записи — повредить таблицу FTL и сделать нечитаемым весь диск, даже если сами ячейки памяти целы. У серверных SSD для этого есть конденсаторы power-loss protection, у бытовых обычно нет.

SSD правда не может отказать так, как HDD — там нет ни головы, ни пластины, которым можно удариться. Но у него свой список причин смерти, не совпадающий с тем, что люди ассоциируют со словом «диск сломался». Оговорка: SMART у SSD хорошо ловит износ ячеек — процесс медленный, предупреждение приходит вовремя, — но плохо предсказывает отказ контроллера или сбой прошивки: это не деградация, а одномоментное событие.

Почему это вообще не главный аргумент за бэкап

Даже если бы SSD никогда физически не отказывал — бэкап всё равно был бы нужен, потому что подавляющее большинство реальных потерь данных вообще не связано с отказом железа. Вот сценарии, где тип диска не имеет значения:

В пяти строках из шести диск полностью исправен в момент, когда данные уже потеряны — удаление, порчу или шифрование делает не диск, а команда, программа или человек поверх него. rm -rf не различает, лежали удалённые байты на флеш-памяти или на магнитных пластинах — пропадают одинаково. «Мой диск надёжный, поэтому бэкап не нужен» отвечает на вопрос про надёжность диска, но не имеет отношения к реальному профилю рисков, где отказ диска — лишь одна и не самая частая строка.

Пример: как вера в миф навредила на практике

Небольшая студия разработки держала сервер с git-репозиториями и базой issue-трекера на паре SSD в программном RAID 1 — бэкапов принципиально не было: «SSD в зеркале, куда ему деваться». Проблема пришла не с диска.

Джуниор-разработчик по невнимательности запустил миграционный скрипт от другого проекта не в том окружении — скрипт удалял и пересоздавал таблицы issue-трекера, штатная операция, просто не для той базы. RAID 1 честно записал изменение на оба зеркальных SSD синхронно, как ему и положено — он реплицирует байты, а не оценивает их смысл. В итоге у команды оказалось два идеально исправных, синхронизированных SSD с одинаково пустой базой — несколько лет истории задач потеряно за секунды. Ни один диск не отказал ни в каком смысле, SMART обоих был безупречен.

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

Что реально нужно бэкапить и как

Раз причина потери данных чаще логическая, а не физическая, вывод простой: бэкап должен пережить не только смерть диска, но и ошибку, сделанную поверх исправного диска. Практически это значит:

• Копия физически изолирована от рабочего сервера — на другом диске, а лучше на другой машине или в другом дата-центре. RAID и снапшоты на том же сервере не годятся как единственная защита — они реплицируют или фиксируют состояние диска, включая ошибочные операции поверх него, как в примере выше.
• Копия версионирована, а не только «последний срез». Если проблему обнаружили не сразу, единственная перезаписываемая копия к этому моменту уже может быть испорчена вместе с оригиналом. Нужна ротация — несколько точек за разные дни.
• Восстановление проверяется на практике, а не только настраивается. Бэкап, который никогда не разворачивали тестово, — это не гарантия, а надежда. Полный разбор бэкапа сервера целиком с проверкой восстановления — в статье бэкап всего сервера целиком.

Минимальный рабочий вариант для VPS — cron-задача с restic, кладущая версионированные снапшоты во внешнее S3-совместимое хранилище, плюс регулярный тестовый restore:

# ежедневный снапшот с ротацией через restic на внешний бакет
0 3 * * * restic backup /var/lib/postgresql/data /opt/app --tag daily
0 4 * * 0 restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Что реально даёт надёжность SSD — и чего она не даёт

Надёжность SSD — не бесполезное свойство, просто она решает другую задачу, чем бэкап. Она снижает частоту механического отказа и повышает устойчивость к ударам и вибрации — реальный плюс при транспортировке и монтаже оборудования. Но она:

• не защищает от человеческой ошибки — rm -rf или UPDATE без WHERE работают на SSD ровно так же, как на HDD;
• не защищает от вредоносного кода — шифровальщику всё равно, на каком носителе шифровать файлы;
• не отменяет собственный список рисков (контроллер, прошивка, питание), просто заменяет одни угрозы на другие;
• не отменяет нужность версионированной внешней копии, потому что бэкап решает задачу «вернуться на нужный момент времени», а не «пережить поломку диска».

Надёжность диска и наличие бэкапа — два независимых параметра эксплуатации, а не взаимозаменяемые меры одного риска.

Частые вопросы