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

После атаки на дата‑центр Яндекса в Сасово я решил на всякий случай сделать резервную копию данных с Яндекс.Диска и обнаружил, что часть файлов в галерее не открывается: в приложении «Ошибка сервера», на части миниатюр код 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 не отрабатывал вообще никогда — репозиторий был повреждён, плюс шесть виртуалок конкурировали за один эксклюзивный лок. Разбираю по шагам, что нашёл и как перестроил схему.

Если вы настраивали аварийное восстановление для OpenStack, то знаете частую проблему: при отказе от Ceph организация безагентной инкрементальной репликации требует поиска альтернативных способов отслеживания изменений.

Самым очевидным кандидатом на эту роль выступает механизм QEMU Dirty Bitmaps — это хорошо изученный в экосистеме KVM/QEMU способ отслеживания измененных блоков (CBT). Однако его использование в OpenStack упиралось в отсутствие штатного API на уровне управляющего слоя. Из-за этого приходилось выбирать между двумя крайностями: строить инфраструктуру исключительно на Ceph или ставить агенты внутрь каждой гостевой ОС.

Ниже расскажу, с какими ограничениями сталкивались наши пользователи раньше, как мы переписали логику работы с инкрементальными данными на уровне гипервизора и что еще полезного появилось в релизе «Хайстекс Акура 4.6».

Опция “С сервера imap.yandex.ru по протоколу IMAP” живёт в личных настройках сотрудника: справка Яндекса адресует все четыре шага владельцу ящика. Документация Яндекс 360 API описывает при этом обратное действие - enable_imap: false ограничивает работу через почтовые программы, причём до тех, кто уже включил доступ себе, этот параметр не достаёт. Разбираю, что эта асимметрия означает для инструментов, которые забирают почту по IMAP, и как за вечер проверить свой на тестовой учётной записи.

Привет, Хабр! Это снова Денис — тимлид инфраструктурной Core-команды в Timeweb Cloud.

В прошлой статье я разбирал живые миграции: NBD, RDMA, switchover за сотни миллисекунд и прочий внутренний хардкор платформы. Там было вкусно инженерам. Сегодня — про другое удовольствие.

Вот у нас снова есть клиент. У него есть сервер. На сервере — жизнь бизнеса: сайт, база, файлы, пара скриптов «временно, но уже третий год». И где-то в голове тихо живёт мысль:

> «Бэкапы? Конечно. Сделаем. После релиза. И отпуска. И вот этого срочного.»

Знакомо до боли. Я как раз собрал сценарий для тех, кто уже устал откладывать и хочет нормальный бэкап без полугодового проекта внедрения. Открываете один файл настроек, запускаете Terraform — и получаете готовую систему резервного копирования в облаке.

Если ждали 40 экранов про внутренности Bareos — выдохните. Сегодня я буду продавать спокойный сон. Он, между прочим, тоже продукт.

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

Глупо отрицать, что разработка в Telegram сопряжена с регулярными техническими рисками в связи со сбоями и блокировками. Сегодня сообщения приходят с задержкой, завтра не загружаются файлы, а через неделю у части пользователей может перестать открываться Mini App.

При этом я уверен, что хоронить Telegram в РФ пока рано. Там остается большая аудитория, бизнес по-прежнему автоматизирует продажи и поддержку, разработчики получают проекты. Но проектировать бота как систему, которая целиком держится на одном мессенджере, уже опасно.

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

Привет, Хабр! Меня зовут Александр Черепанов, я руковожу группой в команде Data Path TATLIN.BACKUP.

Мы уже писали в блоге про наше хранилище. Сначала про то, как с нуля делали дедуплицирующую файловую систему: чанки, FastCDC, протокол T-BOOST. Потом про то, что такое снапшоты, зачем они нужны и как мы их устроили на уровне архитектуры: экстенты, файл как список их идентификаторов, выбор Mark-and-Sweep вместо подсчета ссылок для сборки мусора. С тех пор снапшоты уже почти год в проде, и, судя по отзывам, работают неплохо.

Эта статья принципиально другая. Мы достанем отвертку и залезем внутрь: разберемся, на чем технически строятся снапшоты, как мы их сделали поверх RocksDB, при чем тут LSM-дерево и Bloom-фильтр размером с системный диск ноутбука.

Личная корзина Диска - 30 дней. Корзина организации - “обычно” тоже 30, но по 10 ГБ на сотрудника, без общих дисков и не на всех тарифах. Письма в “Удалённых” - опять 30 дней. А про удаление аккаунта на домене документация говорит коротко: “восстановить данные будет невозможно”. Прошёлся по справке Яндекс 360 и свёл в одну таблицу, где заканчивается каждый штатный механизм восстановления - и что спрашивать со схемы, которая начинается там, где корзины кончаются.

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

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

В этой статье расскажем, почему снапшот — это вообще не бэкап, почему репликация не заменяет резервное копирование, какие требования предъявляются к современной системе защиты данных, и покажем, как эти принципы реализованы в связке VMmanager и RuBackup.