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

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

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

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

У меня где-то 680 GB файлов, из них процентов 90 это фото и видео.

Круговорот файлов в моих хранилищах:

Тут примерная схема того как и где хранятся все мои файлы.

Меня зовут Сергей, я из компании ITSumma, и я хочу вам рассказать, как мы подходим к резервированию в Kubernetes. В последнее время я много занимаюсь консультативной работой по внедрению разнообразных devops-решений для различных команд, и, в частности, плотно работаю по проектам с использованием K8s. На конференции Uptime day 4, которая была посвящена резервированию в сложных архитектурах, я выступал с докладом о резервировании «кубика», и вот его вольный пересказ. Только заранее предупрежу, что он является не непосредственным руководством к действию, а скорее, обобщением размышлений на указанную тему.



В принципе мониторинг и резервирование — это два основных инструмента повышения отказоустойчивости любого проекта. Но ведь в кубере всё балансируется само, скажете вы, всё масштабируется само, и если что-то произойдёт — поднимется само… То есть, при первом поверхностном исследовании темы, на вопрос, кто как подходит к резервированию K8s, интернет ответил мне «а зачем?» Многие думают, что кубер представляет собой такую магическую штуку, которая избавляет от всех инфраструктурных проблем и делает так, что проект никогда не упадет. Но… мир не то, чем кажется.

Сегодня я снова с удовольствием представляю вам полезные советы от моего коллеги Евгения Иванова, тим-лида команды технической поддержки Veeam. На этот раз Женя поделился рекомендациями для работы с бэкапами и репликами. Надеюсь, они помогут вам избежать типичных ошибок, и ваши реплики и бэкапы никогда не будут «слабым звеном» в процессе восстановления, если таковое потребуется.

Итак, добро пожаловать под кат.

Всем привет! Меня зовут Сергей Костанбаев, на Бирже я занимаюсь разработкой ядра торговой системы.

Когда в голливудских фильмах показывают Нью-Йоркскую фондовую биржу, это всегда выглядит так: толпы людей, все что-то орут, машут бумажками, творится полный хаос. У нас на Московской бирже такого никогда не было, потому что торги почти с самого начала ведутся электронно и базируются на двух основных платформах — Spectra (срочный рынок) и ASTS (валютный, фондовый и денежный рынок). И сегодня хочу рассказать об эволюции архитектуры торгово-клиринговой системы ASTS, о различных решениях и находках. Рассказ будет длинный, так что пришлось разбить его на две части.

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

Домашний сервер, где происходит многое из описанного ниже:

Что надо сохранять?

Самое важное и объёмное у меня — фотографии. Изредка видео, но очень изредка — оно слишком много места занимает и слишком много времени отнимает, потому я его не слишком люблю, снимаю только короткие ролики, которые валяются в той же куче, где и фотографии. На текущий момент фотоархив у меня занимает примерно 1,6 терабайта и растёт где-то на 200 гигабайт в год. Другие важные вещи гораздо менее объёмны и с ними меньше вопросов в плане хранения и бэкапа, десяток-другой гигабайт можно распихать по куче бесплатных или очень дешевых мест, начиная от ДВД и заканчивая флэшками и облаками.

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

Масштабировать дисковую инфраструктуру можно не только «вверх», каскадируя JBOD, но и «внутрь», используя различные сценарии заполнения. Как это работает, рассмотрим на примере Western Digital Ultastar Data60.

Сегодня расскажу про две возможности Commvault для резервного копирования MS SQL, которые незаслуженно обходят стороной: гранулярное восстановление и плагин Commvault для SQL Management Studio.  Базовые моменты настройки рассматривать не буду. Пост скорее для тех, кто уже умеет устанавливать агент, настраивать расписание, политики и пр. О том, как устроен Commvault и что он умеет, рассказывал в этом посте.

В этой статье я расскажу, как познакомился с Quest Netvault Backup. О Netvault Backup, когда этот софт еще принадлежал Dell, я уже слышал много положительных отзывов, но мне еще не приходилось его «щупать» руками.

«Да чего же ждать от конференций? Сплошь танцовщицы, вино, гулянки» — шутил герой фильма «Послезавтра».

Наверное, на каких-то конференциях и не такое бывает (делитесь историями в комментах), но на it-сборищах обычно вместо вина пиво (по завершении), а вместо танцовщиц — «танцы» с кодами и информационными системами. 2 года назад мы тоже вписались в эту хореографию, организовав конференцию Uptime day. В этом апреле, на День космонавтики, мы проводим её уже в четвёртый раз — традиционно бесплатно и традиционно под аккомпанемент вопросов «зачем вам это надо?»
На весеннем Uptime day будем говорить об организации резервирования веб-проектов со сложной распределённой архитектурой — способам переключения с боевого окружения на резервное, а также разбору различных сценариев отката и переключения на резервную площадку в случае неудачного деплоя.

А зачем нам это надо?.. Об этом под катом. И о том, чем вам будет полезна конференция Uptime day.

В предыдущей статье мы поведали вам о новых фичах в вышедшем в январе обновлении Update 4 для Veeam Backup & Replication 9.5 (VBR), где осознанно не упомянули бэкапы на магнитную ленту. Рассказ об этой области заслуживает отдельной статьи, потому что новых фич было действительно много.

– Ребята из QA, напишете статью?
– Почему бы и нет!

В данной статье мы рассмотрим наш опыт использования CommVault для резервного копирования PostgreSQL. Для этого разберем небольшую часть одного из наших прошлых проектов, где мы настраивали резервное копирование БД PostgreSQL у клиента.

В прошлых статьях: СХД Infortrend — альтернатива А-брендам и СХД Infortrend EonStor DS2024G2 делался акцент на одно из преимуществ систем хранения Infortrend — поддержка Enterprise SATA SSD в 2-контроллерных системах.
В комментариях читателей возник резонный вопрос: «Насколько отличается производительность SATA-дисков при работе напрямую и через MUX-плату?» В этой статье приводятся результаты тестирования SAN Infortrend DS 2012RE2, на которой был собран RAID10 из 6 Enterprise SSD Intel с интерфейсом SATA. Для тестов использовали 3 способа подключения дисков:

• Прямое подключение (1-контроллерный вариант)
• Подключение через MUX 3G (2-контроллерный вариант)
• Подключение через MUX 6G (2-контроллерный вариант)

В конце января вышло обновление Update 4 для Veeam Availability Suite 9.5, насыщенное фичами как иной полноправный major release. Сегодня я вкратце расскажу об основных новинках, реализованных в Veeam Backup & Replication, а про Veeam ONE обещаю написать в ближайшем будущем. В этом обзоре рассмотрим:

• версии систем и приложений, которые теперь поддерживает решение
• работу с облачными инфраструктурами
• улучшения в резервном копировании
• улучшения в восстановлении
• новое в поддержке vSphere и Hyper-V

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



Итак, добро пожаловать под кат.

1. С чего начать

С чего начинается резервное копирование? Планирование. При резервировании любой системы необходимо составить план резервного копирования: что именно, как часто, как долго хранить, хватит ли свободного пространства? Из ответов на эти вопросы вытекает ответ на главный вопрос – чем бэкапить?

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

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

У Zimbra есть инструмент zmmailbox. И, при ближайшем рассмотрении его функционала, я понял, что его мне будет более, чем достаточно. Он умеет резервировать и восстанавливать ящики даже на живой системе. И мне понравилась возможность делать бэкапы критичных почтовых ящиков отдельно от бэкапа всей системы. Таким образом пространство, занимаемое резервными копиями, будет ограничено размером заархивированных почтовых ящиков, помноженным на количество дней «глубины бэкапа», а не объемом всей системы, помноженной на то же количество дней. К тому же с бэкапа всей системы, в случае с Zimbra, крайне сложно восстановиться. Гораздо проще скопировать виртуальную машину с помощью Veeam или средств управления виртуальной средой (Hyper-V, ESXI, вписать нужное) сразу после настройки системы, и положить «на полочку», чтобы в критичный момент можно было быстро развернуть почти ничего не весящую ВМ и залить в нее бэкапы ящиков. По-моему, это наименее затратный во всех отношениях сценарий.

В конце января Veeam представила обновление для своей платформы управления данными Availability Suite 9.5 — Update 4. Одним из главных нововведений версии стала защита резервных копий ПД в соответствии с требованиями GDPR.

О других обновлениях и чем они будут полезны, рассказываем далее.

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

• быстрое (идеально в фоне);
• сохраняло бы как актуальную версию файлов, так и предыдущие;
• хранилище файлов было бы недоступно вирусам или стихийным бедствиям типа уничтожения носителя или его воровства;
• содержимое резевной копии было бы доступно только пользователю, т.е. паролировалось.

Естественно, простота скрипта обернулась и его недостатками, а именно:

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

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

Всем привет!

Сегодня хочу поведать о том, как управлять Veeam Agent for Linux с помощью командной строки, и о том, какие возможности она открывает в умелых руках программиста.

На написание статьи меня подтолкнул комментарий к предыдущей статье. Перефразирую удивление пользователя: «Ну как же так? Cервер не пишет писем о том, что он забэкапился!». Причём, со слов аналитиков, он не один такой, иначе бы не появился тред на форуме. А раз люди пишут — значит, это кому нибудь нужно!

В статье я поясню, почему этой функции в продукте нет. Но на этом мы не остановимся, мы эту функцию добавим! Мы ж программисты, так что напишем письмо и сгенерируем отчёт в виде html страницы.


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

Приготовьтесь: много кода, картинок нет.

Более пяти лет назад компания Backblaze опубликовала первый отчёт по использованию дисковых накопителей в своих серверах. Backblaze предоставляет услугу дешёвого облачного бэкапа. В основе их инфраструктуры — жёсткие диски потребительского класса. Компания собрала большую статистику по отказоустойчивости разных типов HDD. В то время парк накопителей Backblaze состоял в основном из дисков Seagate, Hitachi и WD, а самыми надёжными оказались диски Hitachi.

С тех пор Backblaze публикует статистику ежегодно, и сейчас пришло время очередного отчёта.

Приветствую всех в новом, 2019 году!

Для начала бросим взгляд назад, то есть на первую часть обзора интегрированного решения Veeam Availability for Nutanix AHV — в ней шел рассказ о том, как развернуть и настроить компоненты. Теперь можно приступить и к настройке резервного копирования, а также познакомиться с вариантами восстановления.

В сегодняшней статье я расскажу про:

• Настройки доступа к репозиторию резервного копирования
• Знакомство с веб-консолью решения
• Резервное копирование
• Восстановление данных
• Ограничения операций

Итак, добро пожаловать под кат.

Новый год начался с новинок от Veeam. На прошлой неделе сервис-провайдерам стал доступен Update 4 для Veeam Cloud Connect. Напомню, Veeam Cloud Connect помогает настраивать репликацию виртуальных машин, запускать реплики в облаке сервис-провайдера, организовывать удаленный репозиторий для бэкапов на площадке провайдера. Я уже писал про этот инструмент тут. Сегодня покажу, что в нем появилось нового.

Вот основные изменения:

• привязка Cloud Gateway к конкретным клиентам;
• репликация в организацию VMware vCloud Director. Раньше можно было делать реплики только на уровне vCenter. У клиентов не было возможности подключиться в реплике виртуальной машины через консоль, не проводя при этом failover.
• бэкап на ленты с привязкой клиента к конкретной ленте.

Подробности под катом.