home.social

#бэкап — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #бэкап, aggregated by home.social.

fetched live
  1. Как я выгружал 1,8 TB с Яндекс Диска после аварии в дата-центрах

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

    habr.com/ru/articles/1095554/

    #md5 #резервное_копирование #vps #бэкап #безлимит #webdav #google_drive #rest_api #яндекс_диск #rclone

  2. Прод лёг вместе с WAF: как я поднимал портал за четыре часа

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

    habr.com/ru/companies/agima/ar

    #восстановление #бэкап #датацентры

  3. Бэкап был, восстановить было нечего: как pg_dump молча собирал битые дампы из-за row-level security

    Если у вас PostgreSQL с включённым row-level security и ночной pg_dump по таймеру, откройте каталог с бэкапами и сравните размеры вчерашнего и позавчерашнего дампов. Если файлы подозрительно одинаковые и маленькие, возможно, у вас нет ни одного рабочего бэкапа. У нас так было не меньше двух недель.

    habr.com/ru/articles/1092008/

    #postgresql #pg_dump #row_level_security #бэкап #systemd #pg_restore #BYPASSRLS #администрирование

  4. Прочитал все комментарии и не стал спорить. Что я поменял в конструкторе ботов за неделю

    Под прошлыми статьями мне написали много неприятного. И почти всё по делу. Отвечать «вы не поняли» было бы проще, но я решил сделать по‑другому: выписал замечания и пошёл их закрывать. Рассказываю, что получилось, а что ещё нет.

    habr.com/ru/articles/1089420/

    #вайбкодинг #бэкап #telegram #конструктор_ботов #mcp

  5. Как проверить бэкап: тест восстановления за один день

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

    habr.com/ru/articles/1082728/

    #drp #бэкап #восстановление

  6. Бэкап, из которого ни разу не восстанавливались — это не бэкап

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

    habr.com/ru/companies/otus/art

    #резервное_копирование #восстановление_данных #PostgreSQL #отказоустойчивость #бэкап #disaster_recovery #мониторинг #инфраструктура #DevOps #безопасность_данных

  7. Как проверить, что бэкап действительно можно восстановить

    У вас есть бэкапы? Хорошо, лёгкий вопрос. А когда вы в последний раз восстанавливали из них хотя бы один файл? Вот она неловкая пауза, понимаю… Между «бэкап есть» и «бэкап восстанавливается» находится пропасть, и в неё регулярно падают даже большие компании. Под катом две страшилки из реальной жизни и разбор того, как проверить свои бэкапы до того, как восстанавливать их придётся на боевом сервере. Читать

    habr.com/ru/companies/ruvds/ar

    #резервное_копирование #бэкап #backup_restore #PostgreSQL #MySQL #mysqldump #binlog #BorgBackup #Linux #ruvds_статьи

  8. PostgreSQL Recovery на пальцах: WAL, base_backup и PITR в Docker-compose

    В этой статье будет разбираться резервное копирование и восстановление PostgreSQL. Покажу все на небольшом практическом docker-compose стенде. Я специально сделаю ошибочное изменение данных, после чего восстановлю базу до состояния непосредственно перед этой ошибкой. Восстановление данных буду делать с помощью второго PostgreSQL контейнера. Если кратко - данные WAL и base_backup будут прокидываться с помощью volume и контейнер будет стартовать с новыми данными. Пока что рабочий стенд будет ограничиваться PostgreSQL 17 в Docker (без S3, Kubernetes, автоматизации и т.п), потом возможно сделаю дополнительные статьи, охватывающие более сложные production случаи.

    habr.com/ru/articles/1076002/

    #postgresql #базы_данных #devops #системное_администрирование #бэкенд #бэкап #восстановление_данных #dockercompose #sql #сервер

  9. Бэкап сайта: кто, когда и зачем должен проверять, что он работает

    Пятничный релиз, база легла, вы берёте архив, а он битый. Часто бэкап сайта воспринимают как архив «на всякий случай». На деле это обязательный регламент. Если проверка бэкапов не проводится регулярно, у вас нет подстраховки. Любой процесс резервного копирования требует жёстких правил. Разберём роли, как составить график, зачем нужно тестирование восстановления и какие уязвимости инфраструктуры закрывает ревизия.

    habr.com/ru/articles/1069362/

    #сайт #бэкап

  10. Ритуалы закончились: разворачиваем систему резервного копирования как код

    Привет, Хабр! Это снова Денис — тимлид инфраструктурной Core-команды в Timeweb Cloud. В прошлой статье я разбирал живые миграции: NBD, RDMA, switchover за сотни миллисекунд и прочий внутренний хардкор платформы. Там было вкусно инженерам. Сегодня — про другое удовольствие. Вот у нас снова есть клиент. У него есть сервер. На сервере — жизнь бизнеса: сайт, база, файлы, пара скриптов «временно, но уже третий год». И где-то в голове тихо живёт мысль: > «Бэкапы? Конечно. Сделаем. После релиза. И отпуска. И вот этого срочного.» Знакомо до боли. Я как раз собрал сценарий для тех, кто уже устал откладывать и хочет нормальный бэкап без полугодового проекта внедрения. Открываете один файл настроек, запускаете Terraform — и получаете готовую систему резервного копирования в облаке. Если ждали 40 экранов про внутренности Bareos — выдохните. Сегодня я буду продавать спокойный сон. Он, между прочим, тоже продукт.

    habr.com/ru/companies/timeweb/

    #бэкап #timeweb_статьи #nbd #rdma #switchover #bacula #vds #postgres #резервное_копирование

  11. Снапшот — это не бэкап, а бэкап — это не гарантия

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

    habr.com/ru/companies/ispsyste

    #бэкап #резервное_копирование #репликация #виртуализация #снапшоты #itинфраструктура

  12. Логи, бэкапы, образы, артефакты: где мы используем S3 внутри Рег.облака

    Привет, Хабр! На связи Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Когда инженеру нужно где-то сложить данные, первая мысль — взять диск побольше. Но внутри нашей инфраструктуры почти всё, что растет и читается параллельно, давно переехало в S3: логи, метрики, бэкапы баз, образы контейнеров, артефакты сборок. Диск остался только там, где он по-настоящему незаменим. В этой статье я расскажу, где именно мы используем объектное хранилище и почему в каждом из этих мест выбрали именно его, а не диск.

    habr.com/ru/companies/runity/a

    #регоблако #s3 #s3server #s3хранилище #k8s #kubernetes #логи #бэкап #метрики #артефакты

  13. С самого начала у нас был четкий план восстановления, и мы его придерживались: как рассчитать честные RTO и RPO

    Классическая ловушка при проектировании отказоустойчивости — разрыв между ожиданиями бизнеса и возможностями инфраструктуры. На бумаге в SLA может быть зафиксировано RTO в 4 часа, но если терабайтный бэкап PostgreSQL физически разворачивается 8 часов из-за лимитов дисковой подсистемы, такой SLA не выдержит первого серьезного инцидента. На практике планы Disaster Recovery (DR) часто пишутся «для галочки» и в полном отрыве от реальной архитектуры. Под катом — техническая изнанка проектирования отказоустойчивости: как приземлить RTO и RPO на реальную инфраструктуру, связать их со стоимостью простоя и взять эти метрики под контроль с помощью правильных инженерных подходов. Также в статью включены практические инструменты: пошаговый чек-лист для безопасного проведения DR-учений и перечень ключевых параметров, которые необходимо непрерывно мониторить для контроля рисков. Кат

    habr.com/ru/companies/hstx/art

    #RTO #RPO #Disaster_Recovery #DRaaS #PostgreSQL #отказоустойчивость #бэкап #репликация #SLA #Хайстекс_Акура

  14. AngaraBase: новая HTAP СУБД

    AngaraBase — OLTP/HTAP СУБД, написанная с нуля на Rust. Совместима с PostgreSQL по протоколу — работает с psql, JDBC, psycopg2 и стандартными драйверами. UNDO-log MVCC без VACUUM, векторизованный исполнитель с SIMD-батчами — транзакции и аналитика под одним SQL и одним снапшотом, без ETL и второго хранилища. Fail-closed контракты ресурсов, USDT-пробы без рестарта, EXPLAIN с разбивкой по фазам исполнения. Dev preview доступен на angarabase.dev.

    habr.com/ru/articles/1053076/

    #HTAP #СУБД #AngaraBase #Rust #MVCC #бэкап #USDT #eBPF #PostgreSQL #векторизация

  15. AngaraBase: новая HTAP СУБД AngaraBase — OLTP/HTAP СУБД, написанная с нуля на Rust. Совместима с PostgreSQL по протоколу — работает ...

    #HTAP #СУБД #AngaraBase #Rust #MVCC #бэкап #USDT #eBPF #PostgreSQL #векторизация

    Origin | Interest | Match
  16. Как быстро восстановить сайты, если нет бэкапов

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

    habr.com/ru/companies/first/ar

    #хостинг #бэкап #восстановление_данных #Wayback_Machine #common_crawl #warc #резервное_копирование #парсинг #CDX_API

  17. Бэкап сайта на шаред-хостинге без cron CLI: bash + lftp + внешний триггер

    Скриптов «забэкапь мне сайт» в интернете тысячи. Большинство падает на shared-хостинге, потому что там либо нет crontab -e , либо нет rsync , либо mysqldump лежит в нестандартном месте, либо у вас нет root, чтобы починить права на /tmp . А ещё — почти все игнорируют ротацию, и через два месяца ваш FTP забит 300 архивами по 200 МБ каждый. В этой статье — рабочая схема для типичного клиентского сайта на Beget/Timeweb/Rusonyx-подобном хостинге, без панельных «бэкап-сервисов» за деньги, с дампом базы, ротацией и без хранения паролей в git.

    habr.com/ru/articles/1046948/

    #бэкап #backup #хостинг #ftp

  18. Инструменты, которые должен знать каждый, кто арендует первый VDS

    Продолжаю серию подборок. Недавно рассказывал про онлайн-сервисы для сетевиков , а сегодня статья для тех, кто арендовал первый виртуальный сервер. Если нужен мониторинг, защита и резервное копирование, но ставить тяжёлый софт ради одной машины не хочется (или не «можется») — эти опенсорсные инструменты вам точно пригодятся. Читать

    habr.com/ru/companies/ruvds/ar

    #VDS #VPS #Linux #open_source #мониторинг #безопасность #бэкап #для_начинающих #инструменты #ruvds_статьи

  19. Александрийская библиотека: краткая история античной системы хранения

    Вчера, если вы не в курсе, в стране отмечался Общероссийский день библиотек. Чем не повод отметить сие событие тематичной статьёй. Она не стала великой сразу и не исчезла в один день. История Александрийской библиотеки — это длинный процесс, длившийся более шести веков: от амбициозного старта к постепенному усложнению и, в конечном счёте, распаду системы, которая удивительно напоминает раннюю версию того, что сегодня называют инфраструктурой хранения данных. Всё началось с власти. Птолемеи, закрепившиеся в конце IV века до н.э. в Египте после распада державы Александра Македонского, строят Александрию как столицу нового типа — не только административную, но и культурную. Библиотека здесь возникает не просто ради собрания книг, а как политический проект: собрать тексты — значит собрать знание, а что знание — сила, понимали уже тогда. Библиотека изначально была встроена в Мусейон — учреждение, которое Страбон в книге «География» описывает как часть царского дворца, где учёные живут, питаются и работают за счёт царя. Это был не архив, а научное производство: свитки не лежали мёртвым грузом, их читали, переписывали, сравнивали, исправляли. Фактически библиотечных собраний было два: главное — в царском дворце в квартале Брухейон, и вспомогательное — в храме Сераписа (Серапеуме), где хранились общедоступные фонды и учебная литература.

    habr.com/ru/articles/1040462/

    #резервное_копирование #архивирование #бэкап #аварийное_восстановление #ленточные_библиотеки #хранение_данных #катастрофоустойчивость #история #античность

  20. Стек российского сисадмина в 2026

    Ушел TeamViewer, Veeam не купить, Jira SM превратилась в тыкву. Собрали актуальный стек российского сисадмина в 2026: шесть категорий, только то что реально работает в проде. Внутри — таблица импортозамещения, честные минусы каждого продукта и чек-лист выживания инфраструктуры. Собрать стек

    habr.com/ru/companies/simpleon

    #импортозамещение #сисадмин #ITAM #itsm #мониторинг #Zabbix #бэкап #удалённый_доступ #Service_Desk #российское_ПО

  21. Не надо так: три типичные ошибки, которые приводят ко взлому

    Забытый бэкап в открытой папке, слабый пароль без двухфакторной аутентификации, сегментация без контроля обходных маршрутов — эти три ошибки делают взлом почти неизбежным. В 2025 году DSEC (команда пентестеров с 23-летним стажем, входит в ГК «Солар») провела 390 пентестов — и в 78% случаев внешний периметр был пробит. Фишинг достигал цели всегда: хотя бы один сотрудник взаимодействовал с письмом — а в 86% случаев вводил пароль или открывал вложение. Но главное — эти сценарии уже реализованы в реальных атаках. Эксперты центра исследования киберугроз Solar 4RAYS ГК «Солар» фиксируют те же векторы: злоумышленники годами живут в сетях, крадут данные или уничтожают инфраструктуру — все из-за таких простых ошибок. Как именно это происходит — разбираем на примерах.

    habr.com/ru/companies/solarsec

    #компрометация #кибератака #кибербезопасность #бэкап #парольная_защита #пентест

  22. Личный архив: сбор, бэкап, таймлайн фотографий

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

    habr.com/ru/articles/1038164/

    #бэкап #резервное_копирование #exif #яндекс_диск #2038 #rclone #cloud

  23. Иллюзия сохранности, или Бэкап, который не спасает

    Случай, произошедший со стартапом PocketOS, выглядел бы комичным, если бы не обернулся реальной катастрофой. ИИ-агент Cursor, работавший на базе Claude Opus, за девять секунд уничтожил не только основную базу данных компании, но и все резервные копии.

    habr.com/ru/articles/1036226/

    #бэкап #резервное_копирование #искусственный_интеллект #информационная_безопасность #распределенные_системы

  24. [Перевод] Стратегия резервного копирования 3-2-1: технический разбор

    У ransomware-операторов теперь есть план: сначала они охотятся за бэкапами, потом — за продакшеном. Перевод технического разбора правила 3-2-1 — что в нём всё ещё работает, что нет и зачем над ним надстроили «1-0».

    habr.com/ru/companies/cloud4y/

    #информационная_безопасность #321 #бэкап #резервное_копирование #itинфраструктура

  25. Весенний релиз. Что мы сделали в Кибер Бэкапе 18.5

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

    habr.com/ru/companies/cyberpro

    #бэкап #восстановление_данных #виртуализация #субд #схд #защита_данных #резервное_копирование #мониторинг

  26. Когда бэкап — последний «выживший»: почему обычные резервные копии не спасают

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

    habr.com/ru/companies/jetinfos

    #срк #резервирование #бэкап #шифровальщик #харденинг #хранилище #изоляция #кибербезопасность #киберпротект #бункер

  27. Неудобные вопросы про бэкап PostgreSQL: где заканчивается СУБД и начинается оркестрация

    Как только очередной вендор обещает «убить нативные тулзы PostgreSQL», где-то устало вздыхает DBA. Попытка сделать бэкап PostgreSQL «лучше самого PostgreSQL» — это изначально неверная постановка задачи. Универсальный файловый агент не притворяется глубоко PostgreSQL-aware решением. Его задача в другом: взять нативные механизмы СУБД и превратить их в управляемый и наблюдаемый процесс на уровне всей инфраструктуры. Вокруг такого подхода обычно сразу возникают неприятные, но правильные вопросы. Кто отвечает за консистентность? Где на самом деле живет PITR? Что будет, если потеряется WAL-сегмент? Можно ли восстановить одну таблицу, а не весь инстанс? И зачем вообще нужен внешний слой поверх pg_probackup, если у PostgreSQL уже есть свои зрелые инструменты? Под катом — честный разговор о границах ответственности между PostgreSQL и внешней платформой. Кат

    habr.com/ru/companies/hstx/art

    #postgresql #резервное_копирование #бэкап #pitr #wal #dba #pg_probackup #срк #оркестрация #восстановление_данных

  28. Неудобные вопросы про бэкап PostgreSQL: где заканчивается СУБД и начинается оркестрация Как только очередной ве...

    #postgresql #резервное #копирование #бэкап #pitr #wal #dba #pg_probackup #срк #оркестрация #восстановление

    Origin | Interest | Match
  29. Безвозвратное удаление — самая сложная операция в ЦОД

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

    habr.com/ru/articles/1008566/

    #ленточные_библиотеки #кибербезопасность #кибератаки #архитектура_систем #резервное_копирование #безвозвратное_удаление #хранение_данных #уничтожение_данных #бэкап #утечки_данных

  30. Почему ваш SSD тихо теряет данные пока он лежит на полке

    У меня есть привычка, которую я не очень люблю: складывать старые накопители в коробку из-под обуви на балконе. Когда кладу, думаю «ну ладно, потом разберусь». На одном фотки из поездки, на другом какие-то рабочие черновики, на третьем вообще непонятно что, но выкинуть жалко, вдруг пригодится. Так вот, «потом» наступило примерно через тринадцать месяцев. Взял оттуда повидавший жизнь SSD (какой-то ноунейм с алика, купленный ради эксперимента), подключил через переходник. Диск опознался, SMART вроде бы в норме. Начал смотреть файлы. Папка с фотографиями открылась, но штук двадцать из трёхсот битые. Превьюшки есть, а сам снимок каша из пикселей, либо вообще ошибка чтения. Архив с документами — «архив повреждён». Ни вирусов, ни падений, ни скачков напряжения. Диск тупо лежал в коробке и забыл часть того, что ему доверили. Я, конечно, знал, что SSD не вечные. Но одно дело знать теоретически, а другое открыть папку и увидеть вместо фоток мусор. Это, мягко говоря, отрезвляет.

    habr.com/ru/articles/1007884/

    #SSD #NAND #флешпамять #хранение_данных #QLC #TLC #квантовое_туннелирование #бэкап #data_retention

  31. Акура-тное приземление. 5 ошибок бэкапа, которые могут стоить вам инфраструктуры

    Представьте: вы прыгаете с парашютом, дергаете кольцо, а из ранца вместо купола вылетает записка: «404: Not Found». В ИТ-инфраструктуре бэкап — именно такой парашют. И проблема в том, что 90% инженеров уверены: раз ранец за спиной висит, значит, гравитация им не страшна. Мало кто проверяет его «укладку» (валидацию) и тренирует само приземление (DR). Чаще всего процесс строится либо на слепой вере в собственную память, либо на тотальном доверии древним скриптам, которые DevOps-археолог написал еще пять лет назад. В момент свободного падения времени на исправление конфигов этих скриптов уже не будет. Поэтому под катом — краткая инструкция по «укладке парашюта»: быстро и без воды про классические ошибки и как их обойти. Дернуть кольцо

    habr.com/ru/companies/hstx/art

    #бэкап #резервное_копирование #Disaster_Recovery #системное_администрирование #информационная_безопасность #RPO #автоматизация #RTO #отказоустойчивость #репликация_данных

  32. Спасаем самое ценное из ChatGPT

    В связи вот с этой новостью " Профессор Кёльнского университета потерял два года работы с использованием ChatGPT " , напоминаю, что ChatGPT тоже можно выкачать данные штатно.

    habr.com/ru/articles/989624/

    #бэкап #chatgpt #всё_пропало

  33. #cloud #clouds #CloudStorage #облака #ОблачноеХранилище #синхронизация #бэкап #Yandex #Яндекс #хуяндекс #акции #скидки

    Видимо, в честь #праздник​а Яша предлагает 2 терабайта на 2 года за 2 136 ₽. Может, кому ннада?

    360.yandex.ru/premium-plans/

    P.S. WebDAV, несмотря на то, что его наличие заявлено, работать не будет. По факту единственный вариант использования — это ихняя родная утилита для синхронизации.

  34. #soooqa Взбрыкнул на несколько секунд драйвер видюхи (от этого обнуляется #LUT). Запустил #Calibrilla, чтобы подгрузить цветовой профиль, и вместо «Из файла» нажал «В файл» 😱 🥶🤯

    Да здравствуют резервные копии! Больше #бэкап​ов, хороших и разных 🙂

  35. @blue
    #юмор
    #утечка_данных
    #бэкап

    Не утечка данных, а...

    **Децентрализованный** **внеплановый**
    **бэкап**

  36. Не утечка данных, а... децентрализованный неожиданный бэкап.

    Это другое, понимать надо.

    #юмор #утечка_данных #бэкап

Share on Mastodon

Enter the server where you have an account.