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

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

Глупо отрицать, что разработка в 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.

Привет, Хабр! Меня зовут Артем Токарь, я младший инженер технической поддержки в К2 Кибербезопасность. Наша команда работает в составе Центра экспертизы по комплексному сервису К2Тех и занимается администрированием средств защиты информации. В том числе мы защищаем сайты заказчиков от веб‑атак — стоим на границе между приложениями и теми, кто к ним обращается.

Я расскажу, как мы искали способ бэкапить свой WAF так, чтобы не разориться на облаке и при потенциальном откате не потерять несколько дней ручной работы.

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

Заказывая бэкап облака, компания незаметно отдаёт наружу три вещи: доступ к данным, ключи шифрования и место хранения. Разбираю по пунктам, как вернуть контроль над каждой - end-to-end шифрование с закрытым ключом только у клиента, запись копий в свой S3, NAS или СХД на территории РФ, запирание выпуска сертификатов на роль owner - и как эта архитектура закрывает требования ФЗ-152. В конце - чек-лист, по которому имеет смысл проверять любой такой инструмент.

Привет Хабр. Мы хотим вам немного рассказать про один интересный недавний ремонт, а так-же свой опыт и инструкцию скачивания прошивки с ПЛИС ALTERA MAX.

Началось все с прибора Fluorophos FLM200 – прибор для проверки качества пастеризации молока.

Хабр, привет! На связи Антон Ботвинников, директор по продукту SDS TROK. 

S3 — модное слово. Его вставляют в питчи, роадмапы и презентации так часто, что даже человек, который не до конца понимает технологию, умудряется звучать убедительно, называя это вслух. Мы тоже решили быть в теме и в новом релизе SDS TROK добавили поддержку S3. Очень просили заказчики. Хочу рассказать, что получилось. 

Привет, Хабр! На связи команда инфраструктурного центра «Инфосистемы Джет».

Давайте договоримся сразу — мы любим, применяем и верим в правило «3-2-1», оно работает. Как базовая гигиена. Но важно то, что после «но». Правило «3-2-1» подробно отвечает на вопрос, как хранить резервные копии. Но почти ничего не говорит о том, что делать, если целью атаки становятся сами резервные копии.

Поэтому теперь мы считаем, что ему не хватает четвертого элемента — мы называем его «Бункер».

У меня есть функция. Крошечная - десяток строк, которые приводят суммы из платёжек к нормальному виду: "1 234,50 ₽" превращают в 1234.5. Ничего гениального. Но я писал её, кажется, раз пять. В парсере банковских выписок, в импортёре заказов, в отчёте для бухгалтерии, в скрипте, который потом выкинул, и ещё где-то, о чём уже забыл.

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

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

Часть 2. Как «Сбросить права доступа» в один клик уносит всю систему, почему я переехал на Proxmox с контейнерами и как менял сетевую папку на Nextcloud с Immich.

Недавно на вебинаре Хайстекс разбирались реальные сценарии DR на практике. В чате трансляции зрители задали ряд технических вопросов, наиболее интересные из них легли в основу этого разбора.

Привет, Хабр. Меня зовут Ори Брук, я ведущий инженер в департаменте разработки объектных хранилищ YADRO. Раньше мы не писали о TATLIN.OBJECT, нашей децентрализованной системе хранения данных (СХД). Исправляемся, ведь у нас есть повод — релиз новой функциональности S3-зеркалирования. Она позволяет бесшовно переносить данные из S3-совместимого хранилища MinIO в нашу СХД. Впрочем, функция может работать с любым S3-совместимым хранилищем в качестве источника данных в рамках поддерживаемых вызовов.

Разберемся, как устроено децентрализованное хранилище, как работает S3 прокси-мигратор, и посмотрим на результаты замеров его производительности на примере MinIO.

В I квартале 2026 года Россия впервые столкнулась с DDoS-атаками мощнее 3 Тбит/с. Атаки стали короче, умнее и опаснее — и защищаться «своими силами» больше не получается. Собрали свежую статистику StormWall и Cloudflare и разобрали, что реально работает против терабитных потоков.

Мой цифровой архив — сканы документов, медицинские снимки, фотографии, видео и аудиозаписи — годами копился в разных местах: на старом и новом компьютерах, в телефоне, облаках и соцсетях. Единого места и понятной системы резервного копирования у этого архива не было.

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

В статье — самый ленивый из работающих способов навести порядок в личном архиве и обеспечить ему бэкап. Без экспертизы в self-hosted сервисах. Только то, что нужно, чтобы перестать откладывать. А в конце — сюрприз: оказалось, что фотолента популярного облачного сервиса имеет проблему Y2038.

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

Ну что же накидаем на пропеллер импортозамещения...

В связи с тем что прошло много лет, но ситуацию можно описать как «нельзя просто так пройти в Мордор» решил поделиться опытом по установке КиберБэкап 18.5 на Астра Linux special edition 1.8.5
Пишу на коленке, прошу ногами не пинать, заранее понять и простить мой русский...

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

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