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

Привет, Хабр! В предыдущих частях руководства мы разобрали rsync вдоль и поперек - от базового синтаксиса до продвинутых "трюков" для бэкапов и деплоя. Казалось бы, вот он, идеальный инструмент на все случаи жизни. Но как часто бывает в IT, универсальных решений не существует.

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

Привет, Хабр! Я Саша, в Хайстекс отвечаю за B2B-продажи и давно работаю с облаками и бэкапом. В этой статье хочу рассказать о подх��де, который, на мой взгляд, помогает закрыть одну из самых болезненных задач в этой области. 

При работе с облачными сервисами часто приходится идти на компромисс: либо хранить дешево, но восстанавливать долго, либо платить за скорость. Допустим, у одного eCommerce-сервиса внезапно упал гипервизор, с ним ушли в офлайн несколько ВМ. Все бэкапы хранились в S3-объектном хранилище. Чтобы восстановить ВМ придется разворачивать ее из архива. На все в среднем уходит около 40 минут. Все это время система заказов лежит, а бизнес считает убытки. С Double Storage мы сделали так, что время восстановления сократилось до 6-8 минут. Что это за технология, как она работает и почему с ней действительно проще – разберём под катом. Технические подробности можем разобрать в комментариях, если будет интерес.

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

Индустрия облачных вычислений переживает свой самый трансформационный период: интеграция искусственного интеллекта стимулирует беспрецедентный рост и меняет то, как компании подходят к цифровой инфраструктуре.

Новые данные показывают, что глобальные расходы на публичные облачные сервисы достигнут $723,4 млрд в 2025 году, что составляет рост на 21% по сравнению с $595,7 млрд в 2024 году.

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

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

Меня зовут Ростислав, я эксперт по разработке ПО отдела систем обработки данных в YADRO. Сегодня разберемся, как устроены наши снапшоты и какие у них особенности. Для этого совершим экскурс в мир систем хранения данных (СХД) и рассмотрим их устройство.

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

Привет, Хабр!

Сегодня расскажем не столько о решении — оно оказалось простым – сколько   о самом процессе его поиска. Он был настолько увлекательным, что в какой-то момент мы почти уверовали в существование магии. Но мы — инженеры, а поэтому как никто знаем, что чудес не бывает. Поэтому, откинув домыслы и иррациональность, мы шаг за шагом распутывали этот технический узел, докапываясь до первопричины проблемы. Приступим же к нашему расследованию. Приятного чтения!

Привет Хабр! Меня зовут Юлия Воробьева, и уже больше 10 лет я занимаюсь тестированием. За это время успела поработать в проектах, связанных с восстановлением, миграцией и резервным копированием данных. Я много занимаюсь облачными технологиями и получаю от этого настоящее удовольствие. Последние 6 лет я работаю в компании Хайстекс, где продукт и задачи позволяют мне не просто тестировать, а прокачивать экспертизу и при этом сохранять интерес к облачным решениям.

В этой статье расскажу, как мы настроили, внедрили и протестировали резервное копирование с решением Хайстекс Акура и S3-хранилищем от Selectel, на основе реальных требований и возможностей компании-клиента. Покажу, как это выглядит на практике глазами QA.

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

Всем привет!

Сегодня поговорим об использовании технологии VMware HotAdd модулем rb_module_vmware СРК. Эффективном методе резервного копирования виртуальных машин без нагрузки на сеть и с минимальным временем простоя.

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

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

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

Увеличению скорости и уменьшению времени восстановления серверов OpenStack и посвящена данная статья.

Мысль написания такой статьи зародилась по итогам обсуждений на форуме iXBT вопроса о том, как организовать хранение в домашних условиях некоторого количества личной информации. Статья "LLM free", все картинки и текст - органического происхождения ;)

Начнем со вводных параметров:

• есть желание сохранить на длительный срок (для конкретности берем 40 лет) данные, при этом сведя к возможному минимуму вероятность их утраты;

• данные включают в себя — электронны�� копии документов, семейные фото, видео. У них есть особое свойство — в случае утраты всех копий восстановление невозможно. Это не фильмы или музыка, которые можно найти в Сети и скачать повторно. Объем данных, по результатам опроса знакомых и коллег — не превышает 1 терабайта;

• человек, озаботившийся сохранением данных — не профессиональный сисадмин, и возможно — даже не связан с IT, поэтому написанием скриптов, постройкой СХД, и установкой в кладовке ленточной библиотеки заниматься не будет, все инструменты должны быть доступны простому обывателю и...;

• ...не требовать чрезмерно много расходов, в идеале — как говорит нам ТРИЗ, «объекта нет — а задача выполняется».

Привет, Хабр!

Эта история произошла в канун Нового года. Один из последних рабочих дней  медленно подходил к концу, мысли уже давно отмечали праздник. Идиллию нарушил звонок коллеги за два часа до окончания смены — мне предложили заняться проблемой функционирования массива Fujitsu AF650 S3. Попытки делегировать диагностику не увенчались успехом – я остался последним. Что ж, вот моя история.

Ни к чему нам лишние переживания за главного героя — Новый год я отметил с семьей за праздничным столом.

Слишком многие люди преступно пренебрегают резервным копированием. Из-за заблуждений в этой области теряется слишком много данных; это связано и с ошибочными техниками наподобие «бэкапов Шрёдингера» (то есть никогда не тестируемых, а значит, валидных и невалидных одновременно), и с концептуальными заблуждениями о том, что такое бэкапы и как они работают (RAID — это не бэкап!).

Сегодня о резервном копировании зачастую думают по остаточному принципу. Многие полностью полагаются на «облако», не задаваясь даже вопросами о том, каким образом защищаются их данные. Большинство упускает из виду, что даже крупные поставщики облачных услуг работают по модели коллективной ответственности. В условиях пользования они часто подчёркивают, что, несмотря на обеспечение ими безопасности инфраструктуры, в конечном итоге ответственность за защиту и резервное копирование данных лежит на пользователях. Когда хранишь всё «в облаке», в кластерах, которыми владеют другие компании, или в распределённых системах Kubernetes, бэкапы часто кажутся ненужными. Иногда я спрашиваю коллег или разработчиков о том, как они реализуют резервное копирование, и они смотрят на меня так, как будто я говорю на каком-то древнем забытом языке. Они попросту никогда об этом не задумывались. Но данные не эфемерны, их необходимо защищать любыми возможными способами.

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

Разработка универсальной системы резервного копирования на языке Python. Как сделать, как применить.

Статья покажет простой rsync скрипт для инкрементального бекапа (с использованием хардлинков из предыдущего бекапа) и про использование btrfs сжатия в zstd.

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

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

В этой статье расскажем:

• какие возможности резервного копирования уже есть в VMmanager;

• как интеграция с RuBackup повышает уровень сохранности данных;

• какие сценарии позволяет реализовать интеграция;

• какие преимущества дает совместное использование двух платформ.

Резервное копирование — критически важная задача. Выполнить её позволит встроенный скрипт от VMware Cloud Director, который можно запустить двумя способами. Первый — с помощью страницы обслуживания (VMware Cloud Director Appliance), второй — вручную (путь: /opt/vmware/appliance/bin/create-backup.sh, или здесь. 

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

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

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

Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.

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

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

Здравствуйте, я загружаю много (как посмотреть) фото (и не только) в Wikimedia Commons. Вместе с Википедией, это важный сервис, особый: некоммерческий, тоже живет на донаты, без рекламы и платных аккаунтов, всё содержимое в свободных лицензиях. Базовый путь загрузки - через веб клиент, который сложный, это не в Фейсбук перетянуть фото. Экосистема, инфраструктура, комьюнити огромно, есть десяток инструментов загрузки. И внезапно, за вечер, я сделал, по моему мнению, один из лучших инструментов, о котором мечтал годами. Получилось так быстро потому что это скрипт для gThumb, который использует официальное SDK Pywikibot на Питоне, и библиотека для чтения/записи IPTC тегов - где указываются категории, категории это важно - Коммонс это не помойка, при загрузке и после ребята стараются систематизировать артефакты, у каждого файла может быть много категорий.

Привет всем, кто заботится о сохранности данных виртуальных машин (ВМ) и не хочет их потерять. Сегодня мы рассмотрим тему бэкапа ВМ на платформе виртуализации oVirt и oVirt-подобных: ROSA; zVirt, РЕД Виртуализация и HOSTVM. Далее в статье, когда будет идти речь о oVirt, подразумевается, что речь будет идти обо всех этих платформах.

Для этого будем использовать систему резервного копирования (СРК) RuBackup.