Бэкап 3-2-1: как я чуть не потерял все фото и что теперь делаю

Andrew30

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

Самое неприятное было не в самом отказе железа, а в том, что я считал себя человеком с бэкапами. У меня ведь была копия на втором диске. Вот только лежала она в том же доме, в том же ящике стола, и последний раз я подключал её больше года назад. То есть фактически у меня была не резервная копия, а вторая закладка на то же самое: один пожар, одна кража, один скачок напряжения в квартире — и я остался бы без всего сразу. Тогда я и полез разбираться, как вообще люди страхуются от такого, и наткнулся на схему 3-2-1.

Схема эта простая до смешного, и именно поэтому её так легко забыть. Три копии данных: одна рабочая и две резервные. Два разных типа носителей: например, внутренний диск ноутбука и внешний жёсткий диск, чтобы поломка контроллера или файловой системы не убила сразу обе копии. И одна копия обязательно вне дома: облако, диск у родителей, сейф на работе, что угодно, лишь бы физически в другом месте. Всё. Больше там ничего нет, и вся магия именно в этой третьей точке, до которой не дотянутся ни пожар, ни вода, ни воры.

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

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

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

Если вы только начинаете, не пытайтесь сразу построить идеальную систему. Возьмите один внешний диск, подключите его, скопируйте туда самое дорогое и поставьте напоминание на каждое первое воскресенье месяца. Потом добавьте облако для документов и фотографий, которые вам важнее всего, и запишите пароли от него туда, где их смогут найти близкие, потому что архив без доступа это просто красивая цифра. А ещё подпишите папки человеческими словами: «Семья 2019», «Документы», «Отпуск Испания». Поверьте, когда придётся восстанавливать всё в спешке, вы скажете себе спасибо за эту мелочь.

Я до сих пор вспоминаю тот щёлкнувший диск, но теперь с благодарностью: он устроил мне дешёвый урок вместо дорогой катастрофы. Друзья, а как устроен бэкап у вас? Есть ли у кого-то копия вне дома, и случалось ли вам восстанавливать данные из резерва так, что вы выдохнули с облегчением? Расскажите, что сработало именно в вашем случае, и заодно поделитесь своим любимым способом проверять копии, ведь чужие истории часто учат лучше любых инструкций.
 
На мой взгляд, контейнеры вредят ровно в тот момент, когда их начинают тащить в проект, где нет ни оркестрации, ни команды, способной это обслуживать. Классика: монолит на пару сервисов и одна база, а поверх уже накручен Kubernetes с ingress-контроллерами, Helm-чартами и тремя окружениями. В итоге время уходит не на продукт, а на отладку YAML и разбор того, почему под снова ушёл в CrashLoopBackOff. Выигрыш от изоляции и масштабирования нулевой, а стоимость эксплуатации выросла в разы.

А вот где контейнеры реально оправданы — это когда есть десятки сервисов с разными зависимостями, потребность в горизонтальном масштабировании и хотя бы один человек, для которого инфраструктура — часть работы, а не побочная нагрузка. Так что вопрос, думаю, не «Docker или не Docker», а «есть ли у нас задача, которую он решает». Интересно, у кого был обратный опыт — когда пришлось откатываться с Kubernetes обратно на что-то простое, и что стало триггером?
 
Согласен с самим тезисом, но с оговоркой: контейнеры вредят не сами по себе, а когда их тащат туда, где спокойно жили systemd и один бинарник. У нас был внутренний сервис на одну реплику, нагрузка — человек двадцать в день. Завернули в Docker, потом «на будущее» прикрутили оркестратор, и в итоге половина инцидентов оказалась не про код, а про сеть, точки входа, тома и про то, что кто-то забыл выставить лимиты по памяти. Разработчики постепенно перестали понимать, где вообще выполняется их приложение, а отладка из «посмотреть логи» превратилась в отдельный квест.

По-моему, водораздел довольно простой: оркестрация оправдана, когда есть настоящее масштабирование, несколько команд и потребность в едином способе доставки. Иначе она превращается в отдельную работу, которую кому-то придётся отдать, — и этот кто-то не появится сам собой. А у вас в команде как определяют ту точку, после которой игра стоит свеч? Или всё-таки проще сразу резать монолит на сервисы в контейнерах, чем потом мучительно переезжать?
 
Честно говоря, я отношусь к тем, кто считает, что контейнеры вредят ровно тогда, когда их тащат туда, где проблемы нет. У меня был проект из трёх сервисов и одной базы — мы зачем-то развернули кластер, и в итоге половина рабочего времени уходила не на продукт, а на борьбу с сетью, томами и обновлениями. Обычный docker compose на одной машине решал ту же задачу за вечер, и всем было спокойнее. Другое дело, когда сервисов становится несколько десятков и нагрузка скачет непредсказуемо: вот там оркестрация реально спасает, и уже никакой ручной деплой не выдержит.

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

Но справедливости ради — контейнеры отлично помогают, когда окружения реально разные и сервисов десятки. Так что вопрос к залу: где у вас проходит та граница, после которой овчинка стоит выделки? И есть ли у кого-то удачный опыт с состоятельными сервисами в кластере, или все всё равно выносят базы наружу и не мучаются?
 
Уже второй год сдерживаю в компании порыв "всё в контейнеры". У нас микросервисов не было изначально — это нормальный монолит, который раз в неделю деплоится и который никто не понимает целиком, но он работает. А Kubernetes у нас тянет два сервиса и базу данных, при этом каждый деплой требует, чтобы все три человека знали, что они делают с манифестами, и у нас нет ни одного человека, который реально понимает, что происходит с сетевыми политиками. Я уже не говорю про то, что observability стоит больше, чем сами серверы. Кому реально нужно, — это отдельный разговор, но "потому что это модно" — это путь в никуда.

А у вас как? Есть ли у кого-то опыт, когда откат от K8s обратно на классический деплой реально ускорил команду? Потому что мне кажется, что все молчат об этом, потому что это "сдаётся назад", а хочется показать, что ты в тренде.
 
Назад
Вверх