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

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

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

Привет, Хабр! Меня зовут Игорь Шишкин, я руковожу командой R&D в облачном направлении Рег.ру и являюсь архитектором наших сервисов — в этой статье расскажу, как мы создавали бэкапы в облаке. Далее о том, как выбирали инструменты для реализации, строили архитектуру и что мы делаем, когда пользователи устраивают тот еще квест — дружно решают забэкапиться в одно время.

В этом обзоре расскажем о проблематике защиты резервных копий, возможных вариантах реализации такой защиты, а также о совместном решении компаний Киберпротект и АМТ‑ГРУП, позволяющем обеспечить защищенное хранение резервных копий, создаваемых СРК Кибер Бэкап, используя аппаратно‑программный комплекс InfoDiode.

Если вы когда-нибудь, запуская рабочую станцию с операционной системой Windows, обнаруживали, что ваш Full HD монитор показывает лишь изображение с разрешением не более 1024x768 и определяется как «Стандартный не Plug-n-Play монитор», и по какой-то причине вы не имеете возможности переключить монитор на другой видеовход, не поленитесь заглянуть под кат, где я растолкую, как «временно» выкрутиться минимальными усилиями.

Привет, Хабр! Меня зовут Валентин, я инженер по тестированию ПО в компании Киберпротект. Сегодня я расскажу о том, как мы продолжаем развивать возможности защиты платформы виртуализации OpenStack в нашей системе резервного копирования Кибер Бэкап. 

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

Сегодня разберем, как это сделать на платформе VMware.

При эксплуатации облаков, в частности приватных, появляется проблема резервного копирования ресурсов облака. Систему резервного копирования RuBackup можно использовать в качестве решения резервного копирования для виртуальных машин в облаках, в том числе на основе VK Private Cloud.

Предположим, что в вашей локальной инфраструктуре уже проинсталирован и настроен экземпляр VK Private Cloud. Чтобы RuBackup смог работать внутри VK Private Cloud, для начала требуется создать пользователя системы виртуализации openstack, от имени которого будет работать модуль rb_module_openstack RuBackup.

В середине апреля вышло обновление нашей системы резервного копирования — Кибер Бэкап 17.3. В этой версии мы обеспечили рывок в производительности системы: относительно максимального числа защищаемых источников данных, дальнейшего развития возможностей работы агентов в многопоточном и кластерном режимах, а также гранулярного восстановления баз данных PostgreSQL.

Помимо этого мы развили защиту платформ виртуализации VMware, oVirt и подобных систем, а также OpenStack. Мы доработали механизмы резервного копирования и восстановления Kubernetes, расширили возможности аудита событий безопасности и интеграции с системами SIEM, внедрили ряд других улучшений.

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

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

Привет, Хабр! Нам в руки попал китайский массив. Но не прям в руки, а удаленно. И даже не один, а сразу два. И даже не Huawei, а Maipu. Если вы еще не знаете, у этого производителя есть официальный сервисный центр в Москве, но об этом позже.

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

Утро в небольшой ИТ-компании обернулось кошмаром — файлы зашифрованы, ERP-система мертва, а на экране требование выкупа.

Всё из-за одной ошибки в настройке RDP. Как хакеры захватили сеть, почему бэкапы подвели и что спасло бизнес?

В формуле идеального решения для резервного копирования данных enterprise-класса много переменных. Одна из ключевых — производительность решения, включая скорость копирования, нагрузку на сеть и потребление вычислительных ресурсов хранилища и источника данных. 

Инженеры компаний YADRO и Киберпротект протестировали совместную работу системы резервного копирования Кибер Бэкап и системы хранения данных TATLIN.BACKUP в трех сценариях сохранения резервных копий виртуальных машин: с inline-дедупликацией, по протоколу NFS и агентом Tboost на узле хранения. Поделимся результатами тестирования совместимого решения, а заодно предметно поговорим об организации правильной архитектуры с учетом особенностей конкретной инфраструктуры.