Как сделать резервную копию debian

Про Debian

Есть миллион способов делать бэкапы. И ещё примерно полмиллиона способов их не делать.
За долгие 10 лет я перепробовал множество способов резервного копирования. Многие из них подводили в самый неожиданный момент, многие были слишком тяжелыми по ресурсам, некоторые были сложными для понимания или скриптования (сложно было оценивать, сделался ли бэкап, даже глазами, не говоря уже об автоматике).
Давайте для начала перечислю, что перепробовал (точнее, чем пользовался достаточно долго, чтобы оценить).

В итоге в какой-то момент я психанул на все эти утилиты. Остановился на связке tar+mysqldump. tar, само собой, не простой, а с инкрементными архивами.
У tar-а в этом месте есть множество минусов — бэкап может быть неконсистентным (если тарится долго — файл1 может отличаться от файла10000000 на час в своём состоянии. Впрочем, этим страдают все file-based утилиты для бэкапов, если вас это не устраивает — то спасут только снапшоты (и снятие копии уже со снапшота)), жрется место как не в себя. Например, если большой файл меняется каждый день — то в каждом архиве этот файл будет целиком. Работает сам tar весьма неторопливо, пару террабайт уже не забэкапишь (впрочем, в век ssd это почти не ощущается). При восстановлении отдельного каталога приходится читать весь архив. Но всё это на практике не имеет смысла против главного плюса — надежности.
Mysqldump тоже не идеальная утилита — там либо скорость, либо консистентность.
Но я рассуждал очень просто — мне нужен был максимально надежный (как в плане создания копии, так и в плане восстановления файлов из неё), максимально универсальный способ забэкапить LAMP-сервер. Там, где есть какие-то особые условия (активная запись, или очень много файлов) — я стараюсь использовать другие решения (в основном, правда, создаю LVM-снапшот, монтирую его и делаю архив, после чего удаляю снапшот, угу). Результатом изысканий табуреточного метода бэкапов и стал скрипт, про который мы поговорим ниже.
Для начала я расскажу, какие конструкции используются в скрипте, в конце уже расскажу, как его ставить-настраивать (он и конфигом оброс, чо уж там).
Основа скрипта — инкрементный tar. Архив создаётся примерно такой командой:

C mysqldump всё ещё проще (ну при условии, что вы создали /root/.my.cnf, как я в какой-то из частей раньше писал):

Если хочется, чтобы сайт при этом не падал (консистентность при этом может пострадать, хоть и дамп потом, конечно, восстановится):

Теперь поговорим о восстановлении. Сразу скажу про mysqldump — с ним попроще.
Сугубо в теории восстановление из mysqldump-а выглядит так:

# zcat /backup/mysqldumps/$.sql.gz | mysql dbname

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

Бывают ещё случаи, когда дамп очень большой базы не восстанавливается (и вам лень разбираться почему, а база хоть в каком-то виде нужна), возможно из-за duplicate keys, возможно из-за ещё чего. В этом случае можно использовать source на дамп из самого mysql.
Для начала положим дамп туда, где пользователь mysql сможет его прочитать (как, впрочем, и другие пользователи. Если понимаете, что делаете — лучше кладите дамп в /var/lib/mysql).

# zcat /backup/mysqldumps/$.sql.gz > /tmp/dump.sql

# mysql

В mysql консоли делаем source:

А дальше уже очень внимательно смотрите, что происходит. Главный плюс source — он не прекращается после первой ошибки. Можно увидеть все ошибки за один проход, поправить их, а потом уже в один заход их исправить (если вообще нужно — на всякие duplicate key пофиг, можно руками потом пофиксить на живой базе). Ну и ещё полезно, что в source практически невозможна ситуация с «не пролез запрос», если речь о действительно огромных таблицах, задампленных одной строкой.

Теперь о таре. Как вообще будут выглядеть копии файловой системы в таре (исходим из того, что вы делаете бэкап раз в сутки). В понедельник мы имеем самый обычный архив, распаковываем файлы из него обычным xvf не заморачиваясь. Во вторник мы имеем уже хитрый архив, в котором написано примерно «удалить файл ХХХ, выкатить новую версию файла УУУ, поменять права на файл ЗЗЗ». Соответственно, если нам нужно состояние каталога за вторник и дальше — придется использовать хитрую конструкцию ниже. Если же нужен отдельный файл за вторник — его, в принципе, можно тоже просто достать через xvf на отдельный архив за вторник.
Но лучше на примерах. Допустим, наш каталог с архивами за прошлую неделю выглядит так (список архивов я взял с одного из реальных бэкапов, чтобы было удобнее):

Допустим, нам нужно распаковать каталог /var/www за понедельник в каталог /restored. Делается легко:

Вообще здесь я упомяну, что НИКОГДА не стоит распаковывать бэкап в каталог, в котором бэкап должен… мхм… быть распакован, что ли. То есть, если хотите восстановить /var/www — сделайте /var/www2, распакуйте архив туда, а потом уже манипулируйте двумя каталогами (www и www2) до нужного результата. Например, сделайте mv www www.current; mv www2 www. Если не заработает — можно будет быстренько откатить на, хотя бы, текущее состоянии до восстановления архива. Иначе каша получится. Ну и руками совместить файлы из двух каталогов потом будет проще.
Ладно, с лирическим отступлением закончили. Теперь мы захотели посмотреть на этот же каталог за среду. Дела. Распаковать нужно 3 архива по очереди вот таким образом (cd сделать не забудьте только):

Распакуется каталог из базового архива, а потом к нему применятся изменения, «упакованные» в двух следующих. Здесь же будет полезно напомнить, что metadata-файлы для распаковки архивов не нужны (только для создания следующего инкремента).
Ладно, знаю, утомил всех, хотя прочитать на досуге советую. Поехали в TLDR.
Качаем мой скрипт и «ставим его»:

Качаем пример конфига:

Добавляем запуск в cron (в моём примере — на 6:00 каждого утра):

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

Источник

Как сделать резервную копию debian

Все мы помним (любим и скорбим) о добром привидении от Нортона – Norton Ghost. В мире Windows его можно считать незаменимым (хотя в конкурентах недостатка нет – прим. ред.). В этой статье мы поговорим о средствах резервного копирования для твоего любимого тукса. Более того, все рассматриваемые средства позволяют создать не просто резервную копию системы, а LiveCD/DVD.

Зачем нужно все это?

Для начала определимся, зачем админу средства для создания LiveCD. Наша цель – резервное копирование системы, но причем здесь LiveCD? Оказывается, это довольно удобно. Мы убиваем вот сколько зайцев сразу:

Не нужно думать, что бэкап в виде LiveCD может использоваться только для копирования/восстановления файлов самой системы. Можно копировать и пользовательские данные из /home, лишь бы их размер не превысил размера DVD-диска. Хотя можно использовать двухслойные диски (двухсторонние использовать не удобно), что позволит увеличить объем резервируемой инфы.

Какие средства мы будем рассматривать?

Самым мощным средством для клонирования твоего тукса является Clonezilla. Этот продукт может не только создать LiveCD, но и развернуть систему по сети. На сайте разработчиков https://clonezilla.org/ можно найти следующую информацию: за 10 минут Clonezilla SE развернул по сети образ 5,6 Гб на 41 компьютер сети. В итоге все компы были настроены всего за 10 минут. Правда, для такой сетевой установки нужно развернуть специальный сервер, но об этом позже. Кроме того, Clonezilla может использоваться для бэкапа компьютеров, работающих под управлением Windows и FreeBSD.

Если тебе не нужно такое мощное средство, можно ограничиться утилитой Remastersys Backup (https://www.geekconnection.org/remastersys/). Правда, эта утилита рассчитана только на Debian и Ubuntu (а также на другие дистрибутивы, основанные на Debian), поэтому она не подойдет тебе, если ты используешь, скажем, Fedora или Mandriva.

Любителям Slackware подойдет скрипт Linux Live (https://www.linux-live.org/). Этот скрипт позволяет создать как LiveCD, так и LiveUSB. Почему именно Slackware описан в этой статье? Да потому что этому отличному дистрибутиву почему-то уделяется мало внимания на фоне «попсовых» дистров вроде Ubuntu.

Подобные утилиты можно найти и для других дистрибутивов, например, утилита mklivecd (подобна Remastersys Backup) используется для создания LiveCD на базе Mandriva. Вот, пожалуй, мы и назвали самое главное. Рассмотреть абсолютно все подобные утилиты мы не можем – журнал-то ведь не резиновый.

Clonezilla: бесплатный аналог Norton Ghost

Основные особенности Clonezilla

Clonezilla – программа непростая, сейчас мы рассмотрим лишь один из примеров ее использования (а именно – создание LiveCD и восстановление системы с его помощью), а познакомиться с остальными возможностями программы можно в документации или на сайте разработчиков.

Итак, для создания/восстановления бэкапа нужно выполнить следующие действия:

Вот и все! Как видишь, все довольно просто. Программа работает с устройствами (дисками, разделами) напрямую, поэтому при создании/восстановлении бэкапа все равно, под какой операционной системой работает компьютер.

Remastersys Backup: бэкап для Debian/Ubuntu

В отличие от Clonezilla, которая напрямую работает с устройствами, Remastersys Backup устанавливается на компьютер, работающий под управлением Debian или Ubuntu, запускается под управлением этой операционной системы и создает ISO-образ системы, под управлением которой она запущена.

Порядок работы с Remastersys следующий: ты настраиваешь свою систему, устанавливаешь Remastersys, запускаешь Remastersys, создаешь ISO-образ, который потом нужно будет записать на болванку.

Первым делом установим Remastersys. Открой файл sources.list:

sudo nano /etc/apt/sources.list

Добавь в него следующую строку

для Lenny:
deb https://www.geekconnection.org/remastersys/repository debian/

для Squeeze:
deb https://www.geekconnection.org/remastersys/repository squeeze/

Для Gutsy и Earlier – до версии 2.0.11-1
# Remastersys
deb https://www.geekconnection.org/remastersys/repository remastersys/

Для Hardy и Newer с родным GRUB (1) — версия 2.0.12-1 и выше
# Remastersys
deb https://www.geekconnection.org/remastersys/repository ubuntu/

Для Karmic, Lucid и Newer с grub2 — версия 2.0.13-1 и выше
# Remastersys
deb https://www.geekconnection.org/remastersys/repository karmic/

Сохрани файл и введи две команды:

sudo apt-get update
sudo apt-get install remastersys

Формат вызова remastersys следующий:

sudo remastersys backup|clean|dist [cdfs|iso] [filename.iso]

Пройдемся по опциям:

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

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

Для создания LiveUSB в Ubuntu используется стандартная программа, запустить которую можно командой Система –> Администрирование –> Создание загрузочного USB-диска. Запусти ее, подключи флешку (4 Гб или больше, 2 Гб будет маловато) и нажми кнопку «Make startup disk». Через некоторое время загрузочная флешка будет готова.

Linux Live: бэкап в Slackware

Теперь очередь дошла и до Slackware. Очень хороший дистрибутив, пусть и не такой удобный, как Ubuntu, зато очень надежный. Для создания LiveCD в Slackware выполни следующие действия:

Summary

Итак, какую прогу выбрать? Если у тебя установлена Debian или Ubuntu, самым простым вариантом будет использование Remastersys Backup. Для бэкапа компов, работающих под самыми разными ОС, подойдет Clonezilla – наверное, лучший выбор для админа. А вот фанатам Slackware должны понравиться скрипты Live, но учитывая, что нужно будет перекомпиливать ядро, наверное, проще будет использовать Clonezilla для бэкапа слаки.

Источник

Как настроить бэкап сервера с Debian 10

Вступление

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

Настройка бэкапов

Для того, чтобы резервное копирование работало правильно, необходимо не хранить резервные копии на том же самом сервере. Поэтому данные мы будем копировать в хранилище данных NetAngels при помощи rsync. Вместо этого хранилища данных можно использовать свой backup сервер. Главное, чтобы он поддерживал rsync.

Для начала установите rsync

Создайте каталог /backup:

Создайте файл /usr/sbin/backup-tar.sh:

Скопируйте в него содержимое ниже:

Для сохранения нажмите на клавиатуре F2.

Установите бит исполнения:

Создайте файл /usr/sbin/backup-rsync.sh:

Измените строку full-backup на путь до папки на втором сервере, где стоит хранить данные. В случае с хранилищем данных NetAngels указывается относительный путь (т.е. без / в начале).

Для сохранения нажмите на клавиатуре F2.

Установите бит исполнения:

Осталось добавить задание в cron. Выполните от пользователя root:

Для сохранения нажмите на клавиатуре F2.

Скрипт бэкапа будет запускаться в 8 утра каждое воскресенье. Скрипт копирования данных на backup сервер linux будет запускаться в 23 часа каждое воскресенье.

Чтобы скрипты бэкапов работали, необходимо чтобы на диске сервера было свободное дисковое пространство.

На этом настройка бэкапа сервера завершена. Готово!

Источник

Резервное копирование в Linux Debian с помощью программы Back In Time

Резервное копирование с помощью Back In Time в Debian и Ubuntu

Обновим сведения о пакетах и установим программу командой:

Или с помощью synaptic.

После установки программы в меню появятся два ярлыка. Один для запуска от имени обычного пользователя, второй для запуска от имени «root». При первом запуске создайте профиль своих будущих бэкапов.

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

Потребуется указать адрес сервера и параметры авторизации на нем.

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

В разделе «Расписание» укажите с какой периодичностью требуется выполнять backup. Есть стандартные варианты. Либо создать собственное расписание выбрав пункт меню «Ручная настройка периодизации». Если этого не требуется то оставьте его в состоянии «Отключен».

На вкладке «Включить» выберите папки и файлы которые хотите включить в резервную копию. Для этого нажмите кнопку «Добавить файл» («Add File») или «Добавить папку» («Add Folder»). Выберите нужные папки и файлы. Если какой то из элементов нужно удалить то нажмите кнопку «Удалить» («Delete»).

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

Следующая вкладка называется «Автоматическое удаление». Не смотря на то, что диски все больше в объемах с каждым годом. Место все же кончается. И здесь мы можем указать как долго требуется хранить резервные копии.

На вкладке «Опции». Я оставляю как есть. Но на ноутбуке отключаю создание резервных копий если он работает от батареи.

Осталась вкладка «Расширенные настройки». Это вкладка для опытных пользователей. Я оставляю всё по умолчанию.

После того как настроили профиль нажимаем кнопку «Ок». Откроется главное окно программы.

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

Назначение кнопок слева на право:

Нажмите кнопку 1 и создайте первую копию.

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

Восстанавливаем данные

Восстановить данные из ранее созданных резервных копий в back in time можно разными способами. Над третьей панелью есть ещё один бок с кнопками:

Можно выбрать нужную копию в главном меню и нажать кнопку номер «3». Можно даже выбрать папку или файл внутри резервной копии и нажав кнопку «3» восстановить их. Второй путь. Нажав кнопку под номером «4» отобразится список сделанных бэкапов.

Здесь можно работать со всеми бэкапами. Восстанавливать, удалять, сравнивать и т.д. Выбрав нужный нажмите на уже знакомую кнопку «Восстановить». После завершения работы все данные будут восстановлены.

Источник

Debian → BackupPC настройка системы резервного копирования Debian / Ubuntu

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

Для работы нам понадобится минимум 2 работающие системы, одна будет выступать в качестве сервера, а вторая в качестве машины резервное копирование которой мы будем проводить.
Для проведения резервного копирования у нас будет создан пользователь, назовем его: backuppc

Переходим к практике.

Настраиваем сервер BackupPC

Для выполнения заданий резервного копирования нам потребуется настроить сервер, который будет хранить сами бэкапы, выполнять подключение к серверам, резервное копирования которых и будет выполняться.
Предполагается что операционная система у вас установлена и настроена как вам требуется.
Для начала установим сам BackupPC
поднимем права до root

Установим требуемые пакеты

ответим на вопросы установщика, по сути это правила для настройки почтовых уведомлений
Определяем тип почтового хоста, я выбрал smarthost — когда почта отправляется через внешний почтовый сервер

Укажем от чего имени будет уходить почта, сервер называется master.example.org — подтягивается из имени системы, но можно указать и свои данные.

Указываем через кого будет отправляться почта. Предполагается что имя почтового сервера smtp.example.org

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

Теперь если мы попытаемся зайти в WEB интерфейс backuppc, то у нас ничего не получится, т.к. у нас требуют пароль для входа, которого у нас нет, для этого нам нужно добавить запись в файл htpasswd, у нас есть 2 варианта генерирования данного пароля:
1) установить apache2-utils

И затем сгенерировать файл командой

указав пароль, получить готовый файл

2) воспользоваться online-генератором
результат работы которого сохраняем в файл:

В общем я заранее «подсуетился» и сгенерировал файл, . ТОЛЬКО ДЛЯ ТЕСТИРОНИЯ. логин backuppc, пароль backuppc

ну и содержимое файла:

Сохраняем изменения и перезапускаем apache

Идем в Web-интерфейс по адресу httр://server_ip_address/backuppc.
Указываем логин и пароль который мы придумали и попадаем в web интерфейс.
В котором пока пусто

Система завелась, а это считай пол дела сделано.

Теперь нам требуется создать ssh-ключ, про сути нам требуется создавать ключ только один раз, в дальнейшем его копировать на другие машины чтобы можно было выполнять подключение по SSH к клиентским машинам, для выполнения резервного копирования

Парольную фразу не указываем, чтобы подключение осуществлялось без ввода пароля для ключа.
Из написанного понятно что мы указываем длину ключа 1024bit, место где его сохранить /var/lib/backuppc/ и имя файла ключа key
В директории у нас появилось 2 файла с именами key и key.pub
key-закрытый ключ, его оставляем на сервере резервного копирования
key.pub — открытый ключ (сертифкат), его мы будем тиражировать на машины, резервное копирование которых будем выполнять, по нему будет выполняться подключение, его можно раскидать по другим машинам, на них генерировать ничего не нужно и этот, рутинный, процесс можно автоматизировать скриптом.

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

Установим права доступа:

Копируем ключ key в директорию .ssh

Установим права на файл ключа:

Предоставим пользователю backuppc права доступа на директорию и файл

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

нам достаточно набрать yes, а соответсвующая запись запись добавится в файл /var/lib/backuppc/.ssh/known_hosts

Нам поможет StrictHostKeyChecking

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

Теперь ввода yes система не потребует, а сервер бэкапов сам будет добавлять записи, по мере их поступления, в файл known_hosts.

Настройка резервного копирования клиентской машины Linux (Ubuntu)

Настройка клиентской машины

Алгоритм действий довольно прост и отлично поддается автоматизации:
1) Создать пользователя backuppс
2) Добавить ему открытый ключ
3) Разрешить вход по ключу на сервере SSH
4) Предоставить необходимые права в системе

1- Создаем пользователя
Пользователя, под которым мы будем запускать выполнение задач резервного копирования, мы назовем backuppc естественно, что на реальных системах, такого делать не стоит и нужно указывать имя отличное от названия ПО — в целях безопасности, ну и чтобы никто не догадался.

и ответим на вопросы системы, указав пароль.

2-Добавляем пользователю открытый ключ
Мы создали пользователя backuppc, теперь нам требуется создать директорию для хранения ключей

Установим права на эту директорию

Копируем ключ key.bub в директорию .ssh тогда путь к нему будет:

Переименовываем key.pub в authorized_keys и предоставляем нужные права доступа.
переименуем файл:

Установим права на файл ключа:

Сделаем пользователя backuppc владельцем директории и файла

3-Разрешаем вход по ключу, на сервере SSH

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

Находим строку и снимаем с нее комментарий

Это говорит системе где искать ключ пользователя и какое имя файла ключа (для этого мы и переименовали key.pub в authorized_keys)

4- Предоставить необходимые права в системе

Предоставляем пользователю backuppc права доступа, чтобы он мог выполнять действия со всеми файлами в системе, а для этого ему нужны права root.
Полный доступ в систему предоставлять не правильно, мы разрешим ему запускать только rsync через sudo чтобы система не спрашивала пароль, больше ничего!
Для этого отредактируем файл

и добавляем туда запись:

Где:
backuppc — имя пользователя
ALL = NOPASSWD: /usr/bin/rsync — задаем права на запуск одного приложения с правами root без пароля, это rsync ну и указываем путь к нему.

Добавим на сервер BackupPC параметры подключения и директорию которую мы хотим бэкапить.

Настройка параметров резервного копирования на сервере BackupPC

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

Перерзайдем под пользователем backuppc

Установим подключение по SSH к удаленному серверу командной.

Соединение установлено и вы попали в консоль удаленного сервера, система не просила набрать yes при подключении и все работает отлично.

Осталось настроить задание.
Выбираем пункт Edit Hosts
И заполняем форму:

Указываем адрес хоста и пользователя под которым выполняется резервное копирование.
И нажимаем Save
Ну и идем в параметры хоста, выбираем пункт Xfer
Важные пункты подчеркнуты

rsync — Метод синхронизации
RsyncShareName — указываем путь к директории, которую мы хотим бэкапить
RsyncClientCmd — параметры подключения к серверу для выполнения резервного копирования
RsyncClientRestoreCmd — параметры подключения к серверу для выполнения восстановления
На последних 2х пунктах остановимся по подробнее
Там указано следующее

Естественно нам оно не подходит, по этому мы сформируем свою команду для выполнения подключения.
Внимание правильный ответ:

Вот тут самая мякотка… Прошу обратить внимание!

Но а в целом, система очень достойная, разобраться с остальным вам в качестве домашнего задания и думаю оно много сил не отнимет.

Куда складываются резервные копии?
В директорию:

На этом все, если есть вопросы, то прошу в комментарии, если нашли ошибку, прошу в личку ну или черкните письмо на почту.

Источник