neqste
Проверенные
- Сообщения
- 191
- Реакции
- 206
- Баллы
- 11,045
Теория
Предисловие
Тут, год назад был написан мною теоретический бред.
В данной статье я попытаюсь описать один из наиболее "простых" и понятных способов созданий резервных копий на выделенных серверах \ VPS с доступом к root.
Статья не претендует на то, "как нужно" делать резервные копии, и возможно вы предложите наиболее оптимальные способы создания резервных копий без лишней головной боли.
С момента написания этого руководства, прошел 1 год, и я не останавливался в поисках надежного, и удобного лично для меня способа создания небольших резервных копий своих различных мелких (и не очень) проектов.
Теория, и опыт вперемешку:
За последнее время я опробовал огромное количество различных способов создания резервных копий, и хочу подвести некоторый минимальный итог, надеюсь многим пригодится.
Список мини выводов.
Пример типичной задачи для создания резервных копий:
Duplicity
Абсолютно все поставленные выше задачи решаются очень просто с помощью Duplicity.
Сайт проекта:
Стабильная версия:
Краткие возможности Duplicity:
Duply
Что такое Duply:
Duply - это "надстройка" над Duplicity, которая позволяет делать все то, что делает Duplicity, но гораздо проще, и с помощью очень простые и очевидных команд. Создается конфиг, в котором описывается все желаемые действия с резервированием, и ставится на крон.
Сайт:
Последняя стабильная версия:
Хранение резервных данных
Данные будут хранится на своем VPS / Dedicated сервере
Данные с сервера на котором будем делать бекапы будем слать на жесткий диск VPS / дедика.
Это один из самых быстрых, но не самый надежный способ хранения информации. (зависит от провайдера).
Список рекомендуемых (цена \ качество):
Передачу данных на свой дедик \ VPS с помощью Duply обычно совершают через ssh (sftp / scp) или rsync, но обычно что бы не морочить никому голову, создают отдельного пользователя на VPS с бекап хранилищем с доступом к домашнему каталогу только для этого пользователя.
Хранение бекапов в облаке
Если выше, мы платим так же за ресурсы \ IP самого сервера, то список провайдеров ниже предоставляют услуги хранения данных, некоторые из них специально заточены для хранения огромных кластеров файлов, одновременно с репликацией по множеству ДЦ. Обычно таким занимаются довольно крупные игроки, а цены в десятки \ сотни \ тысячи раз ниже, чем за содержание своего сервера.
Примеры:
Практика
Как это выглядит:
1. Устанавливаем надстройку над Duply
2. Настраиваем Duply
3. Устанавливаем доп. python модули для поддержки определенных протоколов (python-swift / python-paramiko) в зависимости от выбранного способа передачи данных на сервер где будут хранится резервные копии)
4. Подготавливаем доп. скрипты создания бекапов базы для duply
5. Подготавливаем пост-скрипты по завершению создания бекапа
6. Проверяем работоспособность
7. Настраиваем крон
(Для Ubuntu 14.04+ / Debian 7+)
1. Установка Duply
Для начала необходимо установить ту версию, которая есть в репозитории. А уже позже, обновить до последних с оф. сайта. Можно конечно же сразу установить с сайта, но проще будет сделать так, как озвучено выше (что бы не было проблем с путями к исполняемым файлам).
Зайдите на root пользователя в вашей системе, и приступим.
1.) apt-get update && apt-get install duply python-dev librsync-dev python-setuptools -y обновит индекс пакетов в репозитории, и установит старенькую версию duply, совместно со старенькой версией duplicity, и все необходимые библиотеки для установки новых версий.
2.) cd /tmp && wget https://code.launchpad.net/duplicity/0.6-series/0.6.26/+download/duplicity-0.6.26.tar.gz -O duplicity.tar.gz && tar xzvf duplicity.tar.gz && cd dupli* && python setup.py install перейдем во временную директорию сервера, скачаем 0.6.26 duplicity с оф. сайта (последняя стабильная версия на момент написания руководства), извлечем файлы из архива, перейдем в папку с архивом, и установим duplicity. (все одной командой)
3.) Переходим вот сюда, и качаем последнюю версию Duply:
4.) Заменяем скачанный файл в архиве (duply) с оригинальным установленным на нашем сервере. (находится в /usr/bin), либо просто пишем rm /usr/bin/duply && nano /usr/bin/duply && chmod +x /usr/bin/duply (где во время открытого окна для вставляем скопированный файл (можете открыть в блокноне) duply, после чего нажимаете ctrl + x, потом y, и enter, обязательно проверяем права на запуск. Должно быть что-то вроде этого:
5.)
если не так, то выставить права на запуск можно с помощью
chmod +x $(which duply)
6.) На этом этапе мы закончили половину дела.
2. Настраиваем Duply
Повторюсь, Duply из себя представляет "заготовку"\"надстройку" над Duplicity, в форме конфиг файла, с детальной документацией что где подправить, что бы было хорошо.
Вся настройка Duply сводится к:
1.) Создание профиля для бекапов
duply profilename create будет создан профиль profilename
2.) Переходим в папку где хранится конфиг для вашего профиля
cd /root/.duply/profilename
В папке будет хранится файлик conf (оно же конфиг для вашего профиля)
2.) Настройка конфига для Duply
Конфиг представляет из себя следующее:
Нас интересуют следующие опции:
(шифрование)
GPG_KEY='_KEY_ID_'
или
GPG_PW='_GPG_PASSWORD_'
(способ подключения и передачи данных \ конечная цель где будут хранится бекапы)
TARGET='scheme://user[:password]@host[:port]/[/]path'
бекапы какой папки на сервере будет делать
SOURCE='/path/of/source'
Пример готовой конфигурации (изменены только строки указанные выше):
На этом вся конфигурация завершена (можете снизу по желанию покопаться в опциях, но они не существенны)
(прошу обратить внимание на TARGET='', в зависимости от того, какой способ выберите вы, такие библиотеки и посоветует вам duplicity для установки что бы этот способ работал)
Теперь мы можем создать (проверить) наш первый бекап:
duply profilename backup - т.к. ранее бекапов никаких не было, и подключения к удаленному ssh серверу не было, то потребуется первоначальное (одноразовое) подтверждение ключа (нажимаем Y), и если у вас не установлен необходимый модуль для корректной работы duplicity, duply предложит его установить, и повторить попытку. В нашем случае, этот недостающий для транспортировки файлов через ssh - python-paramiko
Установим его:
apt-get install python-paramiko
Пробуем ввести еще раз в терминал duply profilename backup
Ждем какое-то время для создания первого (полного) бекапа, и вуаля, все готово.
Все последующие вводы команды duply profilename backup будут создавать инкрементные бекапы (различия между полным бекапом, и измененной локальной копией).
Для того, что бы проверить состояние бекапов, можем написать: duply profilename status (отобразит все бекапы которые были сделаны и их время создания).
Но это мы бекапим только папку с файлами, а как же быть с базой?
Для этого в Duply есть поддержка pre / post скриптов (bash).
Нам необходимо по факту сделать следующее:
1.) Создать pre скрипт, в котором с помощью стандартной утилиты mysqldump создадим дамп базы (бекап базы (если это можно так назвать)).
2.) Файл базы будет сохранен в папку которую бекапим
3.) Duply видит новый файл - и отправляет его на сервер
4.) Создадим post файл для удаления созданного дампа базы с сервера
5.) После выполнения бекапа, Duply прочитает post файл, и удалит файл с папки с сайтом.
Пример pre скрипта:
mysqldump -uuser -ppassword database_name > `date +/home/website/database_name.%Y%m%d.%H%M%S.sql`
Пример post скрипта
rm /home/website/database_name*
На этом все, можно попробовать проверить создание бекапов с помощью команд:
Для этого, необходимо отредактировать файл crontab
Пишем в терминал:
crontab -e
Видим нечто похожее на это:
В самом низу добавляем
30 6 * * * duply profilename backup
ctrl +x, y;
Теперь каждый день в 6:30 утра будут автоматические бекапы базы \ файлов форума на наш сервер через ssh.
Восстановление бекапов
Допустим необходимо откатиться до какой-то определенной версии резервной копии (за какой-то день). Для начала нам необходимо узнать время бекапа к которому откатиться, напишем в терминал:
duply profilename status
Увидели нечто подобное (для примера взял свою конфигурацию):
Например нам нужен бекап за 22 июня в 04:50.
duply profilename restore <куда будем сохранять файлы> <возраст \ от какой даты>
Для этого, нам необходимо выполнить:
duply profilename restore /tmp/somefoldername 2015-06-22T04:50:06
Запустится процесс восстановления резервной копии, по окончанию в папке /tmp/somefoldername будет идентичная копия файлов на момент 2015-06-22
Можно так же восстановить самую последнюю версию резервной копии, с помощью:
duply profilename restore /tmp/foldername last
Подводные камни:
1.) Для всех swift (OpenStack) требуется экспортировать TEN**** bla bla name переменную в баш. Для этого в кроне просто прописать EXPORT tenblabla="value", где tenblalbla точное имя которое необходимо, value - значение которое вы получите у провайдера. ( )
2.) Необходимо первоначально вручную подтверждать первый бекап (авторизация \ обмен ключами, и т.п.)
3.) Можно одновременно создавать бекапы в разные ДЦ путем простого копипаста конфига (т.е. pre / post / conf файлов) в новый созданный профиль (duply profile_name create)
4.) Для быстрого переноса с сервера на сервер, можно просто копировать конфиг (+ соответственно необходимо установить duply и необходимые библиотеки для передачи данных по выбранному протоколу)
Предисловие
Тут, год назад был написан мною теоретический бред.
В данной статье я попытаюсь описать один из наиболее "простых" и понятных способов созданий резервных копий на выделенных серверах \ VPS с доступом к root.
Статья не претендует на то, "как нужно" делать резервные копии, и возможно вы предложите наиболее оптимальные способы создания резервных копий без лишней головной боли.
С момента написания этого руководства, прошел 1 год, и я не останавливался в поисках надежного, и удобного лично для меня способа создания небольших резервных копий своих различных мелких (и не очень) проектов.
Теория, и опыт вперемешку:
За последнее время я опробовал огромное количество различных способов создания резервных копий, и хочу подвести некоторый минимальный итог, надеюсь многим пригодится.
Список мини выводов.
- Amazon S3, и прочие "сервисы для хранения информации" это лишь хорошо разрекламированные площадки, которым ничем не уступают в разы дешевле (а то и вовсе бесплатные) аналогичные продукты, и да, они так же теряют данные.
- Резервные копии необходимо хранить зашифрованными, и желательно хранить одновременно в нескольких местах (на случай недоступности одного сервиса, забрать копии с другого) \ ДЦ
- Не рекомендуются никакие php / web-based системы для создания резервных копий. (например ) (не анти-реклама, а просто были случаи на личном опыте из-за ошибок в коде таких вот продуктов)
- Адекватная цена за 1ГБ хранилища где будут расположены резервные копии не должна превышать 0.10 центов.
- Не нужно создавать "велосипеды" со своими батниками, уже все придумано за нас, и придумано такое, что мама не горюй, в этом руководстве опишу только то, что больше всего понравилось мне лично.
- Бекапы необходимо делать несколько раз в день (инкрементные) и обязательный полный бекап.
- Проверяйте резервные копии на восстановление. Если вы не проверяете как оно работает, есть очень большие риски, что вы потеряете в самый нужный момент данные.
Пример типичной задачи для создания резервных копий:
- Допустим есть форум, нужно создавать резервные копии базы форума, файлов форума, и желательно конфигурацию сервера.
- У нас есть доступ к root'у нашей VPS / Dedicated
- На сервере установлен debian / ubuntu (в принципе не важно)
- Все должно быть автоматизировано по максиму
- В случае наступления ЧП, быстро восстановить резервные копии на новом сервере.
- Желательно что бы место выделяемое под резервные копии ничего не стоило, или максимально дешевым.
- Все должно быть автоматизировано
- Должны быть различные способы "передачи" данных между сервером на котором создаются резервные копии, и сервисом \ сервером на котором хранятся данные (SFTP / rsync / scp / swift)
Duplicity
Абсолютно все поставленные выше задачи решаются очень просто с помощью Duplicity.
Сайт проекта:
Стабильная версия:
Краткие возможности Duplicity:
- процесс создание резервных копий предельно прост
- возможность "шифровать" резервируемые данные
- экономит трафик, место на жестком диске (инкрементное резервное копирование)
- огромное количество способов (поддерживаемых протоколов) передачи данных.
Duply
Что такое Duply:
Duply - это "надстройка" над Duplicity, которая позволяет делать все то, что делает Duplicity, но гораздо проще, и с помощью очень простые и очевидных команд. Создается конфиг, в котором описывается все желаемые действия с резервированием, и ставится на крон.
Сайт:
Последняя стабильная версия:
Хранение резервных данных
Данные будут хранится на своем VPS / Dedicated сервере
Данные с сервера на котором будем делать бекапы будем слать на жесткий диск VPS / дедика.
Это один из самых быстрых, но не самый надежный способ хранения информации. (зависит от провайдера).
Список рекомендуемых (цена \ качество):
- , и их места на диске, 128 РАМ, без перебоев в работе, идеально подходит для бекап места для бекапов, т.к. скорость сети очень хороша с любой точки Европы \ США, места навалом, и адекватная цена.
- , 500GB во Франции за 5 евро в месяц.
-
250 ГБ за 10$ в месяц
- - дешевые (ограниченные) VPSки от 6 до 20 евро за от 40 до 500 ГБ места на диске
Передачу данных на свой дедик \ VPS с помощью Duply обычно совершают через ssh (sftp / scp) или rsync, но обычно что бы не морочить никому голову, создают отдельного пользователя на VPS с бекап хранилищем с доступом к домашнему каталогу только для этого пользователя.
Хранение бекапов в облаке
Если выше, мы платим так же за ресурсы \ IP самого сервера, то список провайдеров ниже предоставляют услуги хранения данных, некоторые из них специально заточены для хранения огромных кластеров файлов, одновременно с репликацией по множеству ДЦ. Обычно таким занимаются довольно крупные игроки, а цены в десятки \ сотни \ тысячи раз ниже, чем за содержание своего сервера.
Примеры:
- , 0.01$ за 1 ГБ, репликация сразу в несколько ДЦ. Данные загружаются через swift. Рекомендую.
- , 25ГБ бесплатно, 100 ГБ за 10 евро в год. Скорости не ахти...
- , 15 ГБ бесплатно, скорости бывают и до 10 Гбит\с доходят на аплоад (тестировал со Швеции и Франции)
- , 0.03$ за 1 ГБ ( )
- , 50 ГБ бесплатно, скорости особо не радуют.
- Yandex Disk (через webdav), скорости ужасные
- Можете другие нагуглить, Duplicity поддерживает огромное количество протоколов для передачи данных (swift, webdav, rsync, http, ftp, scp, и т.п.)
Практика
Как это выглядит:
1. Устанавливаем надстройку над Duply
2. Настраиваем Duply
3. Устанавливаем доп. python модули для поддержки определенных протоколов (python-swift / python-paramiko) в зависимости от выбранного способа передачи данных на сервер где будут хранится резервные копии)
4. Подготавливаем доп. скрипты создания бекапов базы для duply
5. Подготавливаем пост-скрипты по завершению создания бекапа
6. Проверяем работоспособность
7. Настраиваем крон
(Для Ubuntu 14.04+ / Debian 7+)
1. Установка Duply
Для начала необходимо установить ту версию, которая есть в репозитории. А уже позже, обновить до последних с оф. сайта. Можно конечно же сразу установить с сайта, но проще будет сделать так, как озвучено выше (что бы не было проблем с путями к исполняемым файлам).
Зайдите на root пользователя в вашей системе, и приступим.
1.) apt-get update && apt-get install duply python-dev librsync-dev python-setuptools -y обновит индекс пакетов в репозитории, и установит старенькую версию duply, совместно со старенькой версией duplicity, и все необходимые библиотеки для установки новых версий.
2.) cd /tmp && wget https://code.launchpad.net/duplicity/0.6-series/0.6.26/+download/duplicity-0.6.26.tar.gz -O duplicity.tar.gz && tar xzvf duplicity.tar.gz && cd dupli* && python setup.py install перейдем во временную директорию сервера, скачаем 0.6.26 duplicity с оф. сайта (последняя стабильная версия на момент написания руководства), извлечем файлы из архива, перейдем в папку с архивом, и установим duplicity. (все одной командой)
3.) Переходим вот сюда, и качаем последнюю версию Duply:
4.) Заменяем скачанный файл в архиве (duply) с оригинальным установленным на нашем сервере. (находится в /usr/bin), либо просто пишем rm /usr/bin/duply && nano /usr/bin/duply && chmod +x /usr/bin/duply (где во время открытого окна для вставляем скопированный файл (можете открыть в блокноне) duply, после чего нажимаете ctrl + x, потом y, и enter, обязательно проверяем права на запуск. Должно быть что-то вроде этого:
5.)
Код:
# ls -lah $(which duply)
-rwxr-xr-x 1 root root 53K Jun 26 2015 /usr/bin/duplychmod +x $(which duply)
6.) На этом этапе мы закончили половину дела.
2. Настраиваем Duply
Повторюсь, Duply из себя представляет "заготовку"\"надстройку" над Duplicity, в форме конфиг файла, с детальной документацией что где подправить, что бы было хорошо.
Вся настройка Duply сводится к:
- Создать профиль (сгенерируется конфиг) для бекапов
- Настроить ключ или пароль для шифрования резервируемых данных
- Выбрать необходимый способ передачи данных (на свой сервер, или в облако (scf / s3 / swift / webdav / ftp)
- Выбрать директорию которую необходимо бекапить
1.) Создание профиля для бекапов
duply profilename create будет создан профиль profilename
2.) Переходим в папку где хранится конфиг для вашего профиля
cd /root/.duply/profilename
В папке будет хранится файлик conf (оно же конфиг для вашего профиля)
2.) Настройка конфига для Duply
Конфиг представляет из себя следующее:
Нас интересуют следующие опции:
(шифрование)
GPG_KEY='_KEY_ID_'
или
GPG_PW='_GPG_PASSWORD_'
(способ подключения и передачи данных \ конечная цель где будут хранится бекапы)
TARGET='scheme://user[:password]@host[:port]/[/]path'
бекапы какой папки на сервере будет делать
SOURCE='/path/of/source'
Пример готовой конфигурации (изменены только строки указанные выше):
На этом вся конфигурация завершена (можете снизу по желанию покопаться в опциях, но они не существенны)
(прошу обратить внимание на TARGET='', в зависимости от того, какой способ выберите вы, такие библиотеки и посоветует вам duplicity для установки что бы этот способ работал)
Теперь мы можем создать (проверить) наш первый бекап:
duply profilename backup - т.к. ранее бекапов никаких не было, и подключения к удаленному ssh серверу не было, то потребуется первоначальное (одноразовое) подтверждение ключа (нажимаем Y), и если у вас не установлен необходимый модуль для корректной работы duplicity, duply предложит его установить, и повторить попытку. В нашем случае, этот недостающий для транспортировки файлов через ssh - python-paramiko
Установим его:
apt-get install python-paramiko
Пробуем ввести еще раз в терминал duply profilename backup
Ждем какое-то время для создания первого (полного) бекапа, и вуаля, все готово.
Все последующие вводы команды duply profilename backup будут создавать инкрементные бекапы (различия между полным бекапом, и измененной локальной копией).
Для того, что бы проверить состояние бекапов, можем написать: duply profilename status (отобразит все бекапы которые были сделаны и их время создания).
Код:
Start duply v1.9.1, time is 2015-06-26 08:32:10.
Using profile '/root/.duply/backup'.
Using installed duplicity version 0.6.26, python 2.7.6, gpg 1.4.16 (Home: ~/.gnupg), awk 'GNU Awk 4.0.1', bash '4.3.11(1)-release (x86_64-pc-linux-gnu)'.
Signing disabled. Not GPG_KEY entries in config.
Checking TEMP_DIR '/tmp' is a folder (OK)
Checking TEMP_DIR '/tmp' is writable (OK)
TODO: reimplent tmp space check
Test - Encryption with passphrase (OK)
Test - Decryption with passphrase (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.2421.1435296730_*'(OK)
--- Start running command STATUS at 08:32:10.607 ---
Duplicity 0.6 series is being deprecated:
See http://www.nongnu.org/duplicity/
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Thu Jun 11 15:30:24 2015
Collection Status
-----------------
Connecting with backend: SSHParamikoBackend
Archive dir: /root/.cache/duplicity/duply_backup
Found 0 secondary backup chains.
Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Thu Jun 11 15:30:24 2015
Chain end time: Fri Jun 26 04:50:30 2015
Number of contained backup sets: 19
Total number of contained volumes: 43
Type of backup set: Time: Num volumes:
Full Thu Jun 11 15:30:24 2015 16
Incremental Sun Jun 14 04:50:03 2015 4
Incremental Mon Jun 15 04:50:04 2015 1
Incremental Tue Jun 16 04:50:04 2015 1
Incremental Wed Jun 17 04:50:03 2015 1
Incremental Thu Jun 18 04:50:04 2015 1
Incremental Fri Jun 19 04:50:03 2015 1
Incremental Sat Jun 20 04:50:03 2015 1
Incremental Sun Jun 21 04:50:03 2015 1
Incremental Mon Jun 22 02:26:38 2015 7
Incremental Mon Jun 22 04:50:06 2015 1
Incremental Tue Jun 23 02:20:11 2015 1
Incremental Tue Jun 23 02:40:28 2015 1
Incremental Tue Jun 23 02:43:20 2015 1
Incremental Tue Jun 23 04:50:07 2015 1
Incremental Wed Jun 24 04:50:33 2015 1
Incremental Wed Jun 24 07:34:38 2015 1
Incremental Thu Jun 25 04:50:07 2015 1
Incremental Fri Jun 26 04:50:30 2015 1
-------------------------
No orphaned or incomplete backup sets found.
--- Finished state OK at 08:32:12.973 - Runtime 00:00:02.366 ---Но это мы бекапим только папку с файлами, а как же быть с базой?
Для этого в Duply есть поддержка pre / post скриптов (bash).
Нам необходимо по факту сделать следующее:
1.) Создать pre скрипт, в котором с помощью стандартной утилиты mysqldump создадим дамп базы (бекап базы (если это можно так назвать)).
2.) Файл базы будет сохранен в папку которую бекапим
3.) Duply видит новый файл - и отправляет его на сервер
4.) Создадим post файл для удаления созданного дампа базы с сервера
5.) После выполнения бекапа, Duply прочитает post файл, и удалит файл с папки с сайтом.
Пример pre скрипта:
mysqldump -uuser -ppassword database_name > `date +/home/website/database_name.%Y%m%d.%H%M%S.sql`
Пример post скрипта
rm /home/website/database_name*
На этом все, можно попробовать проверить создание бекапов с помощью команд:
- duply profilename backup
- duply profilename status
Для этого, необходимо отредактировать файл crontab
Пишем в терминал:
crontab -e
Видим нечто похожее на это:
Код:
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow commandВ самом низу добавляем
30 6 * * * duply profilename backup
ctrl +x, y;
Теперь каждый день в 6:30 утра будут автоматические бекапы базы \ файлов форума на наш сервер через ssh.
Восстановление бекапов
Допустим необходимо откатиться до какой-то определенной версии резервной копии (за какой-то день). Для начала нам необходимо узнать время бекапа к которому откатиться, напишем в терминал:
duply profilename status
Увидели нечто подобное (для примера взял свою конфигурацию):
Код:
Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Thu Jun 11 15:30:24 2015
Chain end time: Fri Jun 26 04:50:30 2015
Number of contained backup sets: 19
Total number of contained volumes: 43
Type of backup set: Time: Num volumes:
Full Thu Jun 11 15:30:24 2015 16
Incremental Sun Jun 14 04:50:03 2015 4
Incremental Mon Jun 15 04:50:04 2015 1
Incremental Tue Jun 16 04:50:04 2015 1
Incremental Wed Jun 17 04:50:03 2015 1
Incremental Thu Jun 18 04:50:04 2015 1
Incremental Fri Jun 19 04:50:03 2015 1
Incremental Sat Jun 20 04:50:03 2015 1
Incremental Sun Jun 21 04:50:03 2015 1
Incremental Mon Jun 22 02:26:38 2015 7
Incremental Mon Jun 22 04:50:06 2015 1
Incremental Tue Jun 23 02:20:11 2015 1
Incremental Tue Jun 23 02:40:28 2015 1
Incremental Tue Jun 23 02:43:20 2015 1
Incremental Tue Jun 23 04:50:07 2015 1
Incremental Wed Jun 24 04:50:33 2015 1
Incremental Wed Jun 24 07:34:38 2015 1
Incremental Thu Jun 25 04:50:07 2015 1
Incremental Fri Jun 26 04:50:30 2015 1Например нам нужен бекап за 22 июня в 04:50.
duply profilename restore <куда будем сохранять файлы> <возраст \ от какой даты>
Для этого, нам необходимо выполнить:
duply profilename restore /tmp/somefoldername 2015-06-22T04:50:06
Запустится процесс восстановления резервной копии, по окончанию в папке /tmp/somefoldername будет идентичная копия файлов на момент 2015-06-22
Можно так же восстановить самую последнюю версию резервной копии, с помощью:
duply profilename restore /tmp/foldername last
Подводные камни:
1.) Для всех swift (OpenStack) требуется экспортировать TEN**** bla bla name переменную в баш. Для этого в кроне просто прописать EXPORT tenblabla="value", где tenblalbla точное имя которое необходимо, value - значение которое вы получите у провайдера. ( )
2.) Необходимо первоначально вручную подтверждать первый бекап (авторизация \ обмен ключами, и т.п.)
3.) Можно одновременно создавать бекапы в разные ДЦ путем простого копипаста конфига (т.е. pre / post / conf файлов) в новый созданный профиль (duply profile_name create)
4.) Для быстрого переноса с сервера на сервер, можно просто копировать конфиг (+ соответственно необходимо установить duply и необходимые библиотеки для передачи данных по выбранному протоколу)
