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

Всем привет. В рамках проекта от компании Acronis со студентами Университета Иннополис (подробнее о проекте мы уже описали это тут и тут) мы изучали последовательность загрузки операционной системы Windows. Появилась идея исполнять логику даже до загрузки самой ОС. Следовательно, мы попробовали написать что-нибудь для общего развития, для плавного погружения в UEFI. В этой статье мы пройдем по теории и попрактикуемся с чтением и записью на диск в pre-OS среде.

10 июля 2020 года австрийская компания Proxmox Server Solutions GmbH представила публичную бета-версию нового решения по резервному копированию.

Мы уже рассказывали, как использовать штатные методы бэкапа в Proxmox VE и выполнять инкрементальный бэкап с помощью стороннего решения — Veeam® Backup & Replication™. Теперь же, с появлением Proxmox Backup Server (PBS) процесс резервного копирования должен стать удобнее и проще.

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

Сегодня я хочу рассказать о нашем опыте автоматизации резервного копирования больших данных хранилищ Nextcloud в разных конфигурациях. Я работаю СТО в «Молния АК», где мы занимаемся конфигурационным управлением IT систем, для хранения данных используется Nextcloud. В том числе, с распределенной структурой, с резервированием.

Проблемы вытекающие из особенностей инсталляций в том, что данных много. Версионирование которое дает Nextcloud, резервирование, субъективные причины, и другое создает много дублей.

Предыстория

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

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

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

Для начала посмотрим на вводные данные. Нам нужно:

• Масштабируемость в плане одна нода или несколько. Для крупных исталляций мы используем в качестве хранилища minio.
• Узнавать о проблемах с выполнением бэкапа.
• Нужно хранить бэкап у клиентов и/или у нас.
• Быстро и легко разбираться с проблемами.
• Клиенты и установки сильно отличаются один от другого — единообразия добиться не получается.
• Скорость восстановления должна быть минимальна по двум сценариям: полное восстановление (дизастер), одна папка — стерто по ошибке.
• Обязательна функция дедупликации.

Для решения задачи управления бекапами мы прикрутили GitLab. Подробнее подкатом.

Несмотря на все карантинные перипетии, дата-центры продолжают работать. Причем с большей нагрузкой, чем раньше, ведь объем интернет-трафика значительно вырос. Какие жесткие диски справятся с работой лучше всего, в очередной раз выяснила компания Backblaze. Известный облачный сервис хранения данных выпустил отчет о надежности HDD — за I квартал 2020 года.

Количество HDD у Backblaze постоянно увеличивается. На момент формирования отчета в распоряжении компании 132 339 дисков. Из них 2 380 — загрузочные, 129 959 — диски для хранения данных. В отчете отображается статистика по отказам дисков разных компаний и разной емкости.

Уже давно известно, что делать бэкапы в SQL-дампы (используя pg_dump или pg_dumpall) – не самая хорошая идея. Для резервного копирования СУБД PostgreSQL лучше использовать команду pg_basebackup, которая делает бинарную копию WAL-журналов. Но когда вы начнёте изучать весь процесс создания копии и восстановления, то поймёте что нужно написать как минимум пару трёхколёсных велосипедов, чтобы всё это работало и не вызывало у вас боль как сверху, так и снизу. Дабы облегчить страдания был разработан WAL-G.

WAL-G – это инструмент, написанный на Go для резервного копирования и восстановления PostgreSQL баз данных (а с недавнего времени и MySQL/MariaDB, MongoDB и FoundationDB). Он поддерживает работу с хранилищами Amazon S3 (и аналогами, например, Yandex Object Storage), а также Google Cloud Storage, Azure Storage, Swift Object Storage и просто с файловой системой. Вся настройка сводится к простым шагам, но из-за того что статьи о нём разрозненны по интернету – нет полного how-to мануала, который бы включал все шаги от и до (на Хабре есть несколько постов, но многие моменты там упущены).

Capacity Tier (или как мы называем его у себя внутри вима — каптир) появился ещё во времена Veeam Backup and Replication 9.5 Update 4 под именем Archive Tier. Заложенная в него идея — это дать возможность перемещать бекапы, которые выпали из так называемого operational restore window, на объектные хранилища. Это помогало расчищать дисковое пространство тем пользователям, у которых его было мало. А называлась сия опция Move Mode.

Для выполнения этого нехитрого (как кажется) действия достаточно было соблюсти два условия: все точки из перемещаемого бекапа должны быть за границами вышеназванного operational restore window, которое задаётся в явном виде в UI. И второе: цепочка должна быть в так называемом «запечатанном виде»(sealed backup chain или Inactive Backup Chain). То есть с течением времени в этой цепочке не происходит изменений.

Но в VBR v10 концепция дополнилась новыми функциями — появился Copy Mode, Sealed Mode и штука со сложновыговариваемым названием  Immutability.

Вот об этих увлекательных вещах мы сегодня и поговорим. Сначала о том, как это работало в VBR9.5u4, а потом об изменениях в десятой версии.



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

• Без малейших сожалений. Автор статьи.

В нынешние времена радуют и стабильность, и новизна. Тут Veeam верен себе: продукты релизятся согласно плану, а инженеры разрабатывают новые решения, среди которых Veeam Backup for Microsoft Azure, который увидел свет несколько недель назад. В прошлом посте мой коллега Loxmatiymamont уже рассказывал о его преимуществах и принципах работы, а сегодня мы рассмотрим процедуры развертывания и настройки нового решения.



Как вы помните, этот продукт предназначен для резервного копирования виртуальных машин, развернутых в облаке Microsoft Azure. Он помогает безопасно и эффективно бэкапить облачные инфраструктуры, а при необходимости и быстро их восстанавливать. Поддерживается интеграция с Veeam Backup & Replication — так что в организациях, работающих с гибридной инфраструктурой, можно развернуть практически целую платформу для работы с виртуальными и физическими машинами как в облаке, так и на своих мощностях.

За подробностями добро пожаловать под кат.

В июньской серии технических вебинаров Hewlett Packard Enterprise мы расскажем вам об актуальных решениях для резервного копирования данных, возможностях экономии на ИТ-инфраструктуре с оплатой по мере потребления, лучших способах хранения VEEAM, защите данных, системе хранения данных для выполнения критически важных задач и не только.

Зарегистрироваться и узнать подробнее о каждом вебинаре вы можете ниже. Полный список вебинаров доступен по ссылке.

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

Как-то я попал под удачную раздачу Яндексом облачного хранилища и заполучил в свое владение 1 Тб. Первое что у меня возникло в голове — это засунуть туда свою iPhoto медиатеку. Живет она у меня на внешнем харде и объем ни много, ни мало — 800 Гб! Казалось бы чего сложного — взял да залил в облако, но…

Информация, загруженная в облако, уже никуда и никогда оттуда не пропадет! Именно так можно сформулировать одну из популярнейших IT легенд, восхваляющую незыблемость облаков и суляющую наступление всеобщего счастья от миграции с банальных on-premise серверов.
Однако на деле всё совершенно не так, и к угрозе потери данных в облаках надо относиться не менее серьёзно, чем к хранящимся на грешной земле. Вот об этом мы сегодня и поговорим: почему облака теряют данные, рассмотрим на примере Azure, какие варианты бекапов нам предлагают облачные вендоры, а на примере Veeam — как эти процессы можно улучшить.

Темой настоящей статьи является подключение к Маку внешних устройств по интерфейсам SAS, Fibre Channel (FC), eSATA. Сразу оговоримся, что для решения задачи доступа к таким устройствам существует путь здорового человека: собрать дешёвый PC, воткнуть туда карту контроллера HBA SAS или FC (например, простейший адаптер LSI), подключить к этому контроллеру свои устройства, установить на PC любой линукс и работать с Мака через сеть. Но это банально и неинтересно. Мы пойдём путём хардкора и будем подключать свои устройства непосредственно к Маку.

По прогнозам IDC, к 2025 году общий объем данных, хранящихся в организациях здравоохранения, вырастет до 2,3 зеттабайт, причем на долю различных медицинских снимков будет приходиться до 80-90% используемой емкости систем хранения. О том, насколько важно эффективное хранение медицинских снимков, говорит следующий пример.

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

В мире наблюдается рост киберпреступности. В прошлом году более 70% компаний подверглись кибератакам. Компрометация персональных данных клиентов и конфиденциальных файлов может иметь серьёзные последствия и приводить к огромным убыткам.

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

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

Полагаю, что многие из вас уже используют для этого Veeam Agent for Microsoft Windows или Veeam Agent for Linux. Если же ещё нет — то, возможно, вас заинтересует сегодняшний краткий обзор. Итак, добро пожаловать под кат.

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

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

Доброго времени суток.
Хочу поделиться с сообществом практическим опытом построения системы хранения данных для KVM с использованием md RAID + LVM.

В программе будет:

• Сборка md RAID 1 из NVMe SSD.
• Сборка md RAID 6 из SATA SSD и обычных дисков.
• Особенности работы TRIM/DISCARD на SSD RAID 1/6.
• Создание загрузочного md RAID 1/6 массива на общем наборе дисков.
• Установка системы на NVMe RAID 1 при отсутствии поддержки NVMe в BIOS.
• Использование LVM cache и LVM thin.
• Использование BTRFS снимков и send/recieve для резервного копирования.
• Использование LVM thin снимков и thin_delta для резервного копирования в стиле BTRFS.

Если заинтересовало, прошу под кат.

Более 4 лет прошло с выхода последнего материала по HPE StoreOnce. Определенно, это недоработка, которую надо устранять.

Не так давно, в городе N одна IT-компания, специализирующаяся на работе с данными клиентов, успешно вела свою работу в своём ДЦ в режиме 24/7. Тот самый случай, когда «сапожник в сапогах», т.е. в IT-компании IT было хорошо отлажено. Интересное началось, когда после многих лет работы свой пост покинул технический директор, который стоял у основ, на котором держался контроль за исправной работой всей IT-вертикали. На смену пришел человек не менее опытный (далее по тексту – “профи”), и даже с более широким кругозором, он буквально очаровал “бизнес” новыми горизонтами развития. Но, как это часто бывает, люди высокого полёта очень неохотно спускаются на землю уровень рядового администрирования.


Хронометраж инцидента:

День первый (апрель): одна местная СХД начала сыпать alert-ами, а потом среди них появились и первые error-ы. Увидев это, админ известил своего руководителя согласно инструкции. Наш профи отмахнулся отпиской ответным письмом, следуя “золотому правилу программиста” – “Работает? Не трогай!”.

Отступление первого дня — Обычно СХД общается с помощью оповещений среди которых стоит выделить Алерты (от “Alert”) – сигналы тревоги. По сути, это оповещения, сигнализирующие о тревожном событии или предупреждающие его. Типы оповещений:
Варнинги (от “Warning”) – предупреждения; как правило дают время спокойно подумать.
Эрроры (от “Error”) – ошибки; например, вылетел диск, но доступ к данным не прервался; здесь уже не стоит откладывать их решение на потом.
Критикал эрроры (от “Critical Error”) – критические ошибки, гарантированно