Резервное копирование *

Серия атак на цифровую инфраструктуру заставила операторов дата-центров пересмотреть привычные модели проектных угроз. Схемы компонентного резервирования N+1 и 2N надежно защищают от предусмотренных проектом отказов: выхода из строя отдельного агрегата, короткого замыкания на вводе или сбоя дизель-генератора. Однако прямое внешнее воздействие развивается иначе: ударная волна, пожар или осколочные повреждения выводят из строя инфраструктуру целыми секторами, из-за чего кабельные трассы, распределительные устройства и контуры охлаждения основной и дублирующей системы могут пострадать одновременно.

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

Привет, Хабр! Я занимаюсь разработкой и продвижением сайтов с 2017, и последний год размышлял, что мне нужен NAS. Долго выбирал и приценивался к готовым решениям на рынке по типу Synology и TerraMaster, но жаба взяла своё. В итоге вспомнил, что у меня в шкафу пылится домашний сервер на винде, который я собирал под ZennoPoster с таким конфигом...

У нас перестали загружаться четыре файла в резервную копию. Дамп PostgreSQL при этом продолжал загружаться. Использовались тот же S3-совместимый сервис, тот же сервисный аккаунт и та же команда aws s3 cp.

Ошибка выглядела достаточно определенно:

В октябре мы выпустили функциональное обновление нашей СРК — Кибер Бэкап 19. В этом обзоре познакомимся с новыми и обновленными функциями, включенными в релиз, а также расскажем о ключевых направлениях развития продукта.

8-11 октября после атак беспилотников пострадали три дата-центра Яндекса: Сасово, Калуга и Владимир. 11 октября Яндекс отключил в веб-версии Диска скачивание папок, альбомов и нескольких файлов сразу. У меня на Диске 1,8 TB файлов и еще около 160 GB фото в безлимите. Терять это не хочется, так что я сел делать бэкап.

План был простой: rclone, VPS в Нидерландах, Google Drive на 2 TB. На деле почти каждый шаг уперся в какую-то особенность Яндекса. Ниже по порядку: что сломалось, какие цифры получились и как обошел. Скрипты и инструкции выложил на GitHub, ссылка в конце.

«Три зоны доступности» внутри одного облака не спасают, когда отказывает само облако. Собираем S3, который переживает отказ провайдера: один endpoint для приложения, за ним несколько облаков, переезд без простоя и без правок в коде. Всё на rclone — union, combine и serve s3. Два режима: старое облако работает или после аварии отдаёт данные только на чтение.

Привет, Хабр. Ранее я писал статью, посвященную недоступности файлам на «Яндекс.Диске». Я разобрал ситуацию подробнее и выяснил — большинство фото можно восстановить даже если они недоступны для скачивания, с видео всё сложнее. Также написал программу для того, чтобы Вы могли скачать свои фото и видео (в том числе с безлимита) уже сейчас, пока они остаются доступными. Разберём ниже.

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

Готового инструмента под эту задачу я не нашёл, поэтому сделал свой. Называется MailBackup, работает под Windows, бесплатный. Ниже расскажу, что он умеет, как устроен и где у него слабые места.

После атаки на дата‑центр Яндекса в Сасово я решил на всякий случай сделать резервную копию данных с Яндекс.Диска и обнаружил, что часть файлов в галерее не открывается: в приложении «Ошибка сервера», на части миниатюр код 500. Скачивание некоторых оригиналов отдает ошибку 504, при этом часть обычных файлов (не из «галереи») также стала недоступна. Подобное поведение проявляется на большей части файлов после вывода из строя утром 11 октября датацентра Яндекса во Владимире. Разберёмся: какие из этих файлов реально не скачиваются, а какие просто теряют превью, как проверить свой Диск и почему копия вне облака не лишняя.

В ночь на 8 октября в Yandex Cloud потеряла электропитание зона доступности ru-central1-b — один из ключевых дата-центров облака. К утру компания сообщила, что работа дата-центра полностью остановлена. Жалобы на сбои начали поступать от пользователей самых разных сервисов: сайтов объявлений вроде «Авито» и «ЦИАН», банков, транспортных порталов, ритейла и других. Утром 9 октября были полностью выведены из строя несколько модулей ещё одного дата-центра Яндекса, в Калуге. На момент подготовки статьи срок восстановления оборудования не назван.

Для инженеров это повод ответить на неудобный вопрос: что будет, если площадка, где расположен прод, внезапно выйдет из строя на неопределённое время? Под катом разберём сценарии отказов инфраструктуры, архитектуру восстановления на независимой площадке и посчитаем RPO и RTO на модельном примере из 40 ВМ.

На Mac с диском 256–512 ГБ место заканчивается регулярно. Обычный путь известен: найти самое большое, перетащить на внешний SSD и удалить оригинал. Если разобраться, что при этом ломается, окажется, что ломается много чего, и чаще всего тихо.

Разбираю грабли: почему сверка копии сразу после записи ничего не доказывает, что exFAT теряет при переносе, какие папки переносить нельзя вовсе, как Docker съедает диск во время архивации томов и как правильно работать с шифрованным образом hdiutil.

В этом году платить за зарубежные облака из России стало почти невозможно. С апреля закрыта оплата сервисов Apple, Google Play не принимает платежи с 2022 года, а Notion отключил российских пользователей ещё в сентябре 2024 года. В комментариях к таким новостям всегда советуют одно и то же: поднимите свой сервер и забудьте о подписках. Я решил проверить этот совет на цифрах. Поднял на своём компьютере Immich, Nextcloud, Vaultwarden и AFFiNE, замерил, сколько им нужно памяти, и сравнил стоимость за пять лет с Яндекс 360 и Облаком Mail. Цены собраны 28 сентября 2026 года. Облако выиграло не на любом объёме: есть граница, после которой свой сервер экономит до 175 тысяч рублей за пять лет. Где она проходит и почему её почти не сдвигает даже б/у железо, разберу по порядку.

Привет, Хабр! Разбирать вопросы после эфиров — полезная практика. В чате трансляции часто поднимают темы, с которыми инженерам приходится сталкиваться на пилотах и в продакшене.

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

Под катом разбор этих тем и линк на демо.

Когда-то эти черные пленочки с негативным текстом рассылались по всему миру тысячами. Инженеры, механики и библиотекари читали с них тексты, используя специальные проекторы. Это был аналоговый интернет своего времени.

А потом пришли 90-е, все бросились оцифровывать архивы, и микрофиши благополучно выбросили на помойку.

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

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

Так может случится в любой момент. Например, если будет взлом  инфраструктуры компании, у которого основной источник общения с клиентов это сайт и почта и “резервные копии хранились на одном сервере с сайтом”, то будет очень печально, тк восстановить будет крайне сложно.

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

Серьезное хранилище резервных копий не просто дедуплицирует данные и не теряет все при вылете одного диска — оно как минимум состоит из двух нод на случай, если одна сломается. Серьезное хранилище умеет делать снапшоты, чтобы злоумышленник не испортил всё, получив доступ к файловым шарам. У такого хранилища есть дедупликация на клиенте. А еще действительно серьезное хранилище умеет реплицировать данные на другую систему. Без всех этих опций индустрия просто не рассмотрит такое Purpose Built Backup Appliance как достойного кандидата занять вакантное место в стойке.

Под катом я расскажу о репликации в TATLIN.BACKUP: зачем нужно, как работает, какие особенности есть.

Как завести свой Git на небольшом VPS и не превратить его обслуживание в отдельный проект? Показываю свой путь с Gitea: настройку пользователей и SSH, перенос репозиториев из GitHub и подключение CI через Gitea Actions. А затем проверяю бэкап делом - восстанавливаю из внешней копии. С командами, ошибками и оговорками по безопасности - для личных проектов и небольших команд.

Полезная внутренняя функция редко остаётся функцией без зависимостей. Сегодня ей понадобился python-dateutil, завтра — конкретная версия NumPy. Когда тот же код нужен во втором проекте, приходится либо менять его lockfile, либо собирать отдельный контейнер, либо превращать десять строк в сервис.

splime предлагает ещё один вариант: опубликовать доверенную Python‑функцию вместе с точными версиями пакетов и вызывать её по имени. Локальный демон сам собирает окружение и хранит его отдельно от проекта, который будет вызывать функцию. Общая модель была в первой статье, а упаковка функции — в предыдущей части. Этот текст можно читать отдельно.

Сначала запустим функцию, чья зависимость вообще не установлена у вызывающего кода. Затем посмотрим, откуда берётся venv, почему он кэшируется и когда одной ноде стоит назначить native, venv-subprocess или Docker. Материал рассчитан на macOS и Linux с Python 3.13+; в splime 0.4.9 сборка локальных окружений требует POSIX.

В комментариях к прошлой статье сформулировали правило, под которым я подписываюсь обеими руками: «платить» за внепроцессный вызов имеет смысл тогда, когда сама работа дороже транспорта. clean_amount из квикстарта — десять строк, ноль зависимостей, микросекунды работы — этот порог не проходит. Свою задачу тот пример выполнил: показал механику publish/call в шесть строк. Но ноды существуют не для него: 2 + 2 через демон не нужно никому, и splime строился не для этого.

Возьмём случай, где оверхед оправдан, залезем под капот и посмотрим, что происходит между publish и call: где физически живёт нода, как Python‑функция превращается в переносимый объект и как две ноды передают друг другу данные, которым не место в JSON.

Напомню контекст из прошлой статьи. splime упаковывает Python‑функции в переносимые вычислительные элементы — ноды, узлы вычислительного графа, — связывает их в пайплайны и исполняет там, где вы скажете: в текущем процессе, через локальный демон или на другой машине.

Всё, что ниже, проверено на актуальной splime 0.4.9.

Бэкапы с моих серверов уезжают в объектное хранилище, и стоило это около десяти тысяч в месяц. Потом пришло письмо, что средства заканчиваются, а по расходу за трое суток выходило уже сорок с лишним. Провайдер ни при чём: репозиторий раздулся до 291 ГиБ, из которых 190 были чистым дублем, а prune не отрабатывал вообще никогда — репозиторий был повреждён, плюс шесть виртуалок конкурировали за один эксклюзивный лок. Разбираю по шагам, что нашёл и как перестроил схему.