Как правильно делать бэкап: важные советы

Предыстория: опыт с Bacula и Bareos

Зависает SD (Storage Daemon). Если у вас настроена параллельность, то обслуживание SD усложняется, а его зависание блокирует дальнейшие бэкапы по расписанию и возможность восстановления.
Нужно генерировать конфиги и клиенту, и директору. Даже если автоматизировать это (в нашем случае в разное время применялись и Chef, и Ansible, и своя разработка), нужно мониторить, что директор после своего reload’а на самом деле подхватил конфиг. Это отслеживается только в выводе команды reload и вызове messages после (чтобы получить сам текст ошибки).
Расписание бэкапов. Разработчики Bacula решили пойти собственным путём и написали свой формат расписаний, который не получится просто распарсить или конвертировать в другой. Вот примеры стандартных расписаний бэкапов в наших старых инсталяциях:
- Ежедневный полный бэкап по средам и инкрементальные в остальные дни:
- Полный бэкап wal-файлов 2 раза в месяц и инкремент каждый час:
- Сгенерированных на все случаи жизни (в разные дни недели каждые 2 часа) у нас получилось примерно 1665… из-за чего Bacula/Bareos периодически сходили с ума.
У bacula-fd (и bareos-fd) на каталогах с большим количеством данных (скажем, 40 ТБ, из которых на 35 ТБ приходятся крупные файлы , а на оставшиеся 5 Тб — мелкие ) начинается медленная утечка памяти, что на production ну совсем неприятная ситуация.
На бэкапах с большим количеством файлов Bacula и Bareos очень сильно зависят от производительности используемой СУБД. На каких она дисках? Насколько мастерски вы умеете её тюнить под эти специфичные нужды? А в базе, между прочим, создаётся одна(!) непартицируемая таблица со списком всех файлов во всех бэкапах и вторая — со списком всех путей во всех бэкапах. Если вы не готовы выделить хотя бы 8 Гб RAM под базу + 40 Гб SSD для вашего бэкап-сервера — сразу готовьтесь к тормозам.
Зависимость от БД достойна ещё одного пункта. Bacula/Bareos на каждый файл спрашивают директора, был ли уже такой файл. Директор, конечно, лезет в БД, в те самые огромные таблицы… Получается, что резервное копирование можно заблокировать просто тем фактом, что одновременно запустились несколько тяжёлых бэкапов — даже если diff’а там на несколько мегабайт.

Обзор AMANDA

По просьбе участника oller добавляю тесты AMANDA,

Программа полностью загружает одно процессорное ядро, но из-за ограниченного по iops диска на стороне сервера хранения резервных копий не может развить большую скорость передачи данных. В целом, настройка доставила чуть больше хлопот, чем у остальных участников, поскольку автор программы не использует в качестве транспорта ssh, а реализует схожую схему с ключами, создавая и поддерживая полноценную CA. Есть возможность широко ограничить клиента и сервер резервного копирования: например, если они не могут полностью доверять друг другу, то можно, как вариант, запретить инициирование восстановления резервной копии со стороны сервера, задавая значение соответствующей переменной в ноль в файле настроек. Есть возможность подключить web-интерфейс для управления, но в целом настроенную систему можно автоматизировать полностью с помощью небольших скриптов на bash (или SCM, к примеру ansible). Существует несколько нетривиальная система настройки хранилища, что, по всей видимости, связано с поддержкой обширного списка различных устройств для хранения данных (кассеты LTO, жесткие диски и т.п.). Также стоит отметить, что из всех программ, рассмотренных в этой статье, AMANDA — единственная, сумевшая обнаружить переименование каталога. Размер репозитория при одном прогоне составил 13 гб.

Анонс

Бэкапы должны быть максимально полные и подробные

Что я имею ввиду? Зачастую бэкапы делаются с расчетом на то, что что-то изменится на проде и нам надо будет развернуть бэкап и посмотреть на него. Бэкапятся, к примеру, исходники сайта и база к нему. Когда все в порядке и ты просто проверяешь бэкап, сложностей не возникает, потому что если ты даже что-то забыл, то залез на prod и посмотрел.

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

Отсюда правило — бэкапьте не только данные, но и все окружение из расчета на то, что вы разом можете потерять prod навсегда. Я много раз об это спотыкался и по второму разу настраивал все то, что у же было настроено ранее. Сейчас все конфиги проектов храню в своем gitlab. Из того, что часто забывают — ssl/tls сертификаты. А потом их приходится торопливо искать.

Бэкапы должны быть максимально полные и подробные

Сторонние утилиты

Handy Backup

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

Genie Timeline

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

Carbone Cope Cloner

Утилита под macOS, создающая дубликат диска. Первые 30 дней использования бесплатны, а после будет необходимо заплатить 2405 рублей. Заходим в программу, в пункте Source Disk выбираем диск, который будем копировать, а в Target Disk указываем место хранения копии – очень просто и быстро.

Helium

Если вы ищете как сделать бэкап на Android – эта программа точно сможет вам помочь. Устанавливаем ее на смартфон и персональный компьютер, после чего подключаем к нему гаджет и синхронизируемся. Далее в мобильном приложении выбираем нужные данные и резервируем их, восстановление проходит по той же схеме. Базовая версия бесплатна, но содержит рекламу, а в платном варианте за 149 рублей можно установить расписание резервного копирования или сохранить данные в облаке.

Облака

Наиболее верным местом для копирования резервной копии являются облачные сервисы. Да, без доступа к интернету данные не извлечь, но это не такая большая проблема как повреждение физического носителя, когда информация утрачивается бесследно. Каждый сам для себя определяет какая платформа ему больше подойдет, но в целом Google Drive, Microsoft OneDrive, Dropbox и Яндекс.Диск прекрасно справятся с поставленными перед ними задачами. Надеемся, теперь ваши данные будут в целости и сохранности.

Выбор места резервирования

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

Внешние диски

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

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

CD / DVD / Blu-Ray диски

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

Двухслойные диски Blu-ray (BD-R) хранят до 50 ГБ, но цены соответствуют этому. И даже при такой емкости резервное копирование на диски будет казаться бесконечно медленным по сравнению с быстрыми жесткими дисками и флешками. Кто хочет постоянно менять местами диски?

Плюсы: дисковые носители дешевы (если они есть в наличии) и очень портативны (всегда рекомендуется хранить резервные копии данных вне офиса).

USB флэш-накопители

Небольшие USB-накопители почти так же дешевы, как и диски. Их преимущество в том, что они ультрапортативны. Может быть, слишком портативны, так как их легко потерять. Но спрятать одну флешку объемом несколько ГБ в сейфе легче, чем хранить оптические или жесткие диски. Некоторые USB-накопители даже предназначены для защиты данных, что делает их более безопасным местом для ваших данных.

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

Сетевое хранилище (NAS)

Устройство NAS – это накопитель (или диски), который находится в вашей сети, поэтому все пользователи в сети могут получить к нему доступ. Иногда NAS называют домашним сервером. Они не всегда дешевы, а некоторые даже не имеют встроенного хранилища – вам придётся покупать диски отдельно. Но с сетевыми хранилищами удобно работать на постоянной основе.

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

В большинстве блоков NAS есть FTP, удаленный доступ в режиме онлайн, элементы управления безопасностью и различные конфигурации RAID для определения того, как диски хранят ваши данные (избыточно или распределено по дискам). Некоторые имеют несколько портов Ethernet, Wi-Fi и USB. Некоторые захватывают ввод с сетевых цифровых видеокамер. Варианты кажутся почти бесконечными, поэтому стоит выбрать подходящий вариант для дома или офиса.

Копирование в облако

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

Если у вас только несколько небольших файлов для хранения, и у вас, вероятно, есть учетная запись Google / Яндекс, тогда используйте Документы Google или Яндекс.Диск. Доблявть файлы или целые папки так же просто, как перетащить их в список документов, если вы используете браузер Chrome.

Грамотно подбираем и тестируем хранилище своих бекапов +10

20.07.15 10:15

•
Loxmatiymamont
•
#261595
•
Хабрахабр

•

8649

Системное администрирование, Резервное копирование, Восстановление данных, Виртуализация, Блог компании «Veeam Software»

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

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

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

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

Чем и как будем тестировать?

IometrFIOFlexible I/O testerтутСамое интересное для нас в секции :

size=100g
Указывает размер тестового файла. который будет создан на объекте тестирования. Основное правило — чем больше, тем лучше

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

bs=512k
Самый важный параметр, когда речь идёт о выжимании всех соков и поиске максимальных скоростей

Жизненно важно правильно указать размер блока данных когда речь идёт о тестировании конкретных сценариев. В нашем случае всё можно найти в документации. И важный нюанс — будем использовать половинные значения как средний ожидаемый выигрыш от использования встроенной в Backup&Replication дедупликации. Соответсвенно если не планируете дедуплицировать вовсе, то берёте целое значение.
Итак, возможные варианты:512К, если установлен Local Target;
256K, если установлен Lan Target;
128K, если установлен Wan Target;

Для обладателей действительно больших инфраструктур, где ежедневный инкрементный бэкап доходит до терабайтов есть смысл использовать 2048К если установлен Local target 16 TB т.к. там размер блока равен 4096К
numjobs=1
Количество параллельно выполняемых задач. Просто начните с единицы и увеличивайте пока не увидите явной деградации.

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

ioengine=windowsaio
Если хранилище будет подключено в Windows серверу, оставляем так. Если к Linux, то заменить на libaio. Оба метода используют небуферизируемое IO, поэтому все кэши на пути до хранилища будут проигнорированы, что нам как раз и требуется.

iodepth=1
Количество процессов, одновременно работающих с файловой системой. В нашем случае всегда 1.

direct=1
Говорим fio не использовать файловый кэш системы для операций чтения и записи. Этим мы симулируем самый плохой случай когда системный кэш забит и не принимает данные.
Отдельно можно эмулировать использование кэша для операций записи. Для этого меняем direct=0 и добавляем опцию invalidate=1.
И надо отметить, что direct=0 нельзя использовать для Linux репозиториев с libaio механизмом.

overwrite=1
Рандомная перезапись блоков. Как зачастую и происходит в реальной жизни. Для тестирования хранилища под использование “тяжелых” вариантов бэкапов, таких как forward incremental, опция строго обязательна.

Как сделать бэкап прошивки Андроид через Recovery без рут прав

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

Убедитесь, что заряд смартфона более 60%.
Выключаем телефон, примерно через 30 секунд зажимаем кнопку включения и качельку громкости вниз или вверх, на разных моделях по-разному.
Далее может появиться изображение робота Андроид с восклицательным знаком. Если это произошло – зажимаем аналогичное сочетание клавиш, но не удерживаем. Сразу перешли в recovery? Тогда данный пункт пропускаем.
Теперь попадаем в само меню рекавери, вот только здесь сенсорный ввод уже не работает. Переключаться будем клавишами: качелька увеличения громкости, соответственно, представляет собой команду «вверх», качелька уменьшения громкости – «вниз», кнопка включения/выключения – «Окей».
Спускаемся до пункта «backup/restore, кликаем «backup». Начинается процедура копирования, которая занимает в среднем до 10 минут. В этот промежуток времени ничего не нажимаем, не включаем смартфон, просто ждем.
Когда операция заканчивается, перегружаем смартфон. Вот и все, готово, бэкап прошивки на Андроид сделан.

Обзор BackupPC

По просьбе участника vanzhiganov добавляю обзор BackupPC. Данное ПО устанавливается на сервер хранения резервных копий, написано на perl, работает поверх различных средств резервного копирования — в первую очередь rsync, tar. В качестве транспорта используется ssh и smb, также в наличии есть web-интерфейс на основе cgi (разворачивается поверх apache). В web-интерфейсе есть обширный список настроек. Из особенностей — наличие возможности задания минимального времени между резервными копиями, а также периода, в течение которого резервные копии не будут создаваться. При выборе файловой системы для сервера резервного копирования надо следить за поддержкой жестких ссылок. Таким образом, файловую систему для хранилища не разобьешь на точки монтирования. В целом, достаточно приятное впечатление, давайте посмотрим, на что способно это ПО:

В целом видно небольшое преимущество по скорости у rsync, также rsync экономнее работает с сетью. Отчасти это может быть скомпенсировано меньшим использованием cpu с tar в качестве программы для создания резервных копий. Другим преимуществом rsync является работа с инкрементальными копиями. Размер репозитория при создании полных резервных копий одинаков, составляет 16 гб, в случае инкрементальных копий — 14 гб за один прогон, что означает работающую дедупликацию.

Google Cloud Storage

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

А для копирования данных в GCS предусмотрен удобный способ — Data Transfer. С его помощью можно создать полную копию бакета, а дальше уже работать с ним по своему усмотрению.

Последовательность действий:

Выключаем Vault.
Заходим в Data Transfer (https://console.cloud.google.com/transfer/cloud).
Выбираем исходный бакет, вводим название бакета, куда переносить данные, и выбираем разовую операцию. Здесь возможно установить и операцию по расписанию, но она не учитывает специфики Vault (тот факт, что сервис необходимо остановить Vault на время её выполнения), поэтому оставляем разовый запуск.
После успешного копирования запускаем Vault.
С созданным бакетом можно работать: например, скачать его содержимое при помощи , заархивировать все данные и отправить на долгосрочное хранение.

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

Скриншоты страницы при создании трансфера и после завершения:

Этап 3. Как восстановить базу данных (БД)

Внимание! Перед тем как начинать применять эту инструкцию, обязательно удостоверьтесь, что у вас сохранена резервная копия базы данных. Входим в панель управления сайтом (вероятно, у вас это CPanel)

Войти в нее можно через браузер, набрав в адресной строке cpanel.АдресВашегоСайта

Входим в панель управления сайтом (вероятно, у вас это CPanel). Войти в нее можно через браузер, набрав в адресной строке cpanel.АдресВашегоСайта.

Далее находим в разделе “Базы данных” меню php MyAdmin и кликаем по нему. В открывшемся окне видим много всякой всячины, но надо не растеряться и найти среди закладок “Базы данных”. : ) Извините, что пишу таким языком, но когда в своих попытках восстановить блог я добралась до этого момента, у меня уже была не то что растерянность, а самая настоящая паника. Кликаем по этой закладке, а потом по названию базы данных вашего сайта. После этого вы увидите таблицу.

Выделяем галочками все ее элементы и нажимаем… УДАЛИТЬ!!! Все, поврежденная база данных удалена. Теперь надо восстановить тот вариант, который был до неудачного обновления или эксперимента.

После удаления БД вы увидите страницу с закладками. Нам нужна закладка SQL. В ней будет пустое поле, в которое надо скопировать текст из файла с расширением .sql. Вставляя текст в это поле, не спешите, это займет от минуты до трех. Не нажимайте несколько раз “вставить”!

Теперь подробнее о том, как найти файл базы данных с расширением .sql.

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

Откройте еще раз распакованный архив (из которого вы уже скопировали файлы в папку public_html). Найдите в списке директорий папку, имя которой содержит backupBD (например, называться она будет вот так User_backupBD, где вместо User будет ваше имя пользователя базы данных).

Откройте файл, выделите все и нажмите «копировать». В поле, указанное выше, и нужно “вставить” этот текст.

Все, теперь база данных должна работать, и сайт в этот момент становится доступен.

Интерпретируем результаты

	512K	256K	128K
Forward / 1 thread	76 iops / 39068 KB/s140,64 GB в час	142 iops / 36476 KB/s131,31 GB в час	232 iops / 29864 KB/s107,51 GB в час
Forward / 2 threads	127 iops / 65603 KB/s236,17 GB в час	239 iops / 64840 KB/s233,42 GB в час	409 iops / 52493 KB/s188,97 GB в час
Forward / 4 threads	161 iops / 82824 KB/s298,16 GB в час	312 iops / 80189 KB/s288,68 GB в час	624 iops / 79977 KB/s287,91 GB в час
Synthetic / 1 thread	32 iops / 17108 KB/s61,59 GB в час 30,79 реальный объём в час	42 iops / 11061 KB/s39,82 GB в час 19,91 реальный объём в час	66 iops / 8590 KB/s30,92 GB в час 15,46 реальный объём в час
Synthetic / 2 threads	48 iops / 25198 KB/s90,71 GB в час 45,35 реальный объём в час	71 iops / 18472 KB/s66,50 GB в час 33,25 реальный объём в час	112 iops / 14439 KB/s51,98 GB в час 25,99 реальный объём в час
Synthetic / 4 threads	58 iops / 30360 KB/s109,29 GB в час 54,64 реальный объём в час	99 iops / 25424 KB/s91,52 GB в час 45,76 реальный объём в час	174 iops / 22385 KB/s80,58 GB в час 40,29 реальный объём в час
Reversed / 1 thread	36 iops / 19160 KB/s68,97 GB в час 22,99 реальный объём в час	50 iops / 12910 KB/s46,47 GB в час 15,49 реальный объём в час	68 iops / 8777 KB/s31,59 GB в час 10,53 реальный объём в час
Reversed / 2 threads	52 iops / 27329 KB/s98,38 GB в час 32,79 реальный объём в час	76 iops / 19687 KB/s70,87 GB в час 23,62 реальный объём в час	109 iops / 14085 KB/s50,70 GB в час 16,90 реальный объём в час
Reversed / 4 threads	66 iops / 34183 KB/s123,06 GB в час 41,02 реальный объём в час	100 iops / 25699 KB/s92,51 GB в час 30,84 реальный объём в час	172 iops / 22006 KB/s79,22 GB в час 26,41 реальный объём в час
Forward incremental forever / 1 thread	31 iops / 16160 KB/s58,17 GB в час 29,09 реальный объём в час	41 iops / 10806 KB/s38,90 GB в час 19,45 реальный объём в час	54 iops / 7081 KB/s25,49 GB в час 12,74 реальный объём в час
Forward incremental forever / 2 threads	48 iops / 25057 KB/s90,21 GB в час 45,10 реальный объём в час	66 iops / 17075 KB/s61,47 GB в час 30,73 реальный объём в час	95 iops / 12304 KB/s44,29 GB в час 22,15 реальный объём в час
Forward incremental forever / 4 threads	57 iops / 29893 KB/s107,61 GB в час 53,80 реальный объём в час	88 iops / 22770 KB/s81,97 GB в час 40,98 реальный объём в час	150 iops / 19323 KB/s69,56 GB в час 34,78 реальный объём в час

Практика: автоматизируй это [с GitLab]!

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

Примечание: Именно GitLab был выбран в качестве средства автоматизации, потому что он удобен для поставленной задачи и в нашем случае есть практически везде. Но должен заметить, что он ни в коем случае не является необходимостью.GitLab и репозиторий

— расписание бэкапов,
— простой скрипт бэкапа файлов (как в примере выше).

ПервымвторымGitLab RunnerСам CI-сценарий

SSH-ключПользователь

Как создать резервную копию текстовых сообщений на Android

В сообщениях может быть важная информация, которую не хочется потерять

Давайте разбираться с еще одной опцией, доступной владельцам Google Pixel, но не доступной «простым смертным» — синхронизацией СМС. Тут сервисы Google нам уже, увы, не помогут. А там, где «бессилен» Google, мы можем найти помощи у сторонних приложений. В данном случае хотелось бы посоветовать бесплатное приложение SMS Backup & Restore.

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

Скачать: SMS Backup & Restore

Яндекс Диск

фото: Yandex

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

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

Яндекс Диск Про предоставляет следующие расширенные тарифы:

100 ГБ: 83 рубля в месяц (при оплате за год) или99 рублей помесячно;
1 ТБ: 209 рублей в месяц / 300 рублей ежемесячно;
вариант на 3 ТБ дает доступ к подписке Плюс с выгодными предложениями от компании: 542 рубля в месяц / 750 рублей в месяц;
если подписки на Яндекс.Плюс уже есть, 3 ТБ обойдутся в 438 рублей в месяц / 630 рублей в месяц.

Изначально доступны 10 ГБ свободного бесплатного места на диске.

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

Мобильные устройства

Как сделать бэкап на компьютере, мы уже расписали

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

Как же сделать бэкап такого устройства?

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

Основные принципы

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

Регулярность – бэкап должен войти в привычку как чистка зубов, тогда ситуация с потерей данных будет практически исключена;
Проверка – после того как копия была создана, ее сразу же надо проверить

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

Бэкапы файлов

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

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

Google Drive

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

Яндекс Диск

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

Dropbox

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

С точки зрения работы тут все реализовано таким образом, чтобы вы вообще не ощущали использование облачных технологий: приложения делают свою работу незаметно для вас. На iOS это может стать отличной альтернативой файловой системе, которой там в полноценном формате нет. Dropbox легко интегрируется в ОС, и вы сможете сохранять все входящие файлы на почту, скачанные в браузере (в том числе и сторонних) сразу туда. Это удобно.

Минус в том, что бесплатный объем — всего 2 Гб, а вот платные тарифы идут сразу от 1 Тб — и за не совсем демократичные деньги. Стоит ли оно того, хватит ли бесплатного лимита — решать только вам.

Обложка: Witthaya — stock.adobe.com

Выводы

PostgreSQL занимает уверенное первое место по скорости создания бэкапа. Raft не так сильно отстает от лидера на небольшом объеме секретов, но разница заметно возрастает при увеличении количества данных. Однако в то же время Raft явно лидирует в скорости восстановления.

Если сравнивать удобство, то Raft и Consul — максимально простые: для выполнения бэкапа и восстановления достаточно выполнить буквально одну команду. GCS же предоставляет встроенный функционал в UI для копирования бакетов: на мой вкус, это немного сложнее, однако для других пользователей может быть плюсом, что все действия выполняются мышкой в браузере. Но в GCS есть существенная проблема с отсутствием гарантий по времени создания снапшотов: одинаковый набор данных может бэкапиться как за 1 час, так и за 3-4 часа.

Помимо производительности и удобства есть и другой критерий — надежность. Вывод, казалось бы, довольно банален: чем менее надежен бэкенд, тем легче его бэкапить

Хотя Vault сам по себе позиционируется как приложение категории cloud native, его бэкап полностью зависит от выбранного бэкенда, и во многих случаях мы получим простой, что недопустимо для такого важного сервиса:

В Consul можно ожидать проблем с чтением и записью при бэкапе/восстановлении данных.
А у PostgreSQL — при восстановлении.
У GCS — проблема другого характера: нет гарантий на скорость копирования.

UPD. Дополнение к GCS по информации от Oleksandr Melnyk (за что ему большое спасибо!). С этим решением есть и другие проблемы: сложно делать бэкапы чаще, чем раз в сутки; не хватает метрик и логов чтобы построить алертинг и проанализировать время выполнения и ошибки задания; затруднительно восстановить объекты по определенной дате.

Получается, что все эти решения имеют серьёзные недостатки, которые могут быть недопустимы в production. Понимая это, в HashiCorp и создали своё оптимальное решение — Integrated Storage (Raft). В нём получается делать бэкапы полностью беспростойно и при этом быстро.

В итоге: если вам важна максимальная скорость для снятия и восстановления бэкапов, то подойдут PostgreSQL и Raft. В первом случае, однако, надо повозиться с удобством: чтобы все правильно настроить и автоматизировать, придется потратить время (и иметь экспертизу). Наш текущий выбор пал на Integrated Storage (Raft) как самый простой в использовании и надежный бэкенд.