Backupservers start
Утилиты для бэкапов
Burp
Burp - клиент-серверная программа для резервного копирования. Есть центральный сервер для хранения копий и клиенты, которые к нему подключаются и копируют на него информацию.
Установка
# apt-get install burp
Запуск серверной части
# systemctl enable --now burp-server.service
Настройки
При обычной настройке файл конфигурации сервера будет находится /etc/burp/burp-server.conf, а файлы конфигурации, специфичные для клиента, будут находиться в каталоге /etc/burp/clientconfdir.
Многие глобальные параметры, установленные в burp-server.conf, могут быть переопределены для каждого клиента через файлы /etc/burp/clientconfdir.
Добавление нового клиента
На сервере
Каждый клиент должен быть представлен на сервере в каталоге /etc/burp/clientconfdir.
Итак, чтобы добавить клиент с именем 'data_store', вам нужно создать на сервере файл /etc/burp/clientconfdir/data_store, который должен содержать как минимум такую строку (если вы не используете пароль, пропишите опцию password_check = 0):
password = abcedfgh
На клиенте
Теперь вам нужно установить burp на клиенте и отредактировать клиентский файл burp.conf.
Чтобы:
- строка «cname» соответствует имени файла clientconfdir на сервере
- строка «password» соответствует содержимому файла clientconfdir
- строка "server" должна содержать адрес сервера.
В нашем примере эти три строки будут выглядеть так:
cname = data_store password = abcdefgh server= 1.2.3.4
При первом подключении нового клиента к серверу он выполнит обмен SSL-сертификатами.
Добавление задания по времени
Для планирования задания по времени используйте cron или systemd-timers.
Отключение клиента
Чтобы помешать клиенту успешно взаимодействовать с сервером, вам следует переместить файл /etc/burp/clientconfdir/<client> в другое место. Клиент, если он еще существует, будет продолжать попытки подключения.
Например:
# mv /etc/burp/clientconfdir/<клиент> /etc/burp/clientconfdir/<клиент>.disable
Тем не менее, это не остановит клиента, пытающегося подключиться к серверу на основе его задания. Если вы все еще можете получить доступ к клиенту, я бы порекомендовал отключить задание.
Рабочий каталог и методы восстановления
https://burp.grke.org/docs/working_dir.html
Whilst a backup is taking place, the server will create a directory in the storage area for the client with a number and a timestamp. For example:
/var/spool/burp/<client>/0000027 2015-04-12 01:24:29
During backup phases 1 (file system scan) and 2 (send actual data), there will be a symlink pointing to the directory called 'working':
/var/spool/burp/<client>/working -> 0000027 2015-04-12 01:24:29
During backup phases 3 (manifest generation) and 4 (shuffling), the symlink will be renamed to 'finishing':
/var/spool/burp/<client>/finishing -> 0000027 2015-04-12 01:24:29
When the backup is complete, the symlink will be renamed to 'current':
/var/spool/burp/<client>/current -> 0000027 2015-04-12 01:24:29
If there is some error that happens during the backup and the backup is
interrupted, the burp server needs to decide what happens next. The behaviour
of what happens next is triggered the next time that the client contacts the
server.
If the interruption left a 'finishing' symlink behind, the server will attempt to carry on and complete the backup. Part of phase 4 may involve operations that alter the immediately previous backup (it may need to convert its files into reverse deltas), so once it is 'finishing', burp can only try to move forwards. Note that when the backup is 'finishing', no more data is required from the client.
If the interruption left a 'working' symlink behind, the server will check the 'working_dir_recovery_method' server-side option to decide what to do next. There are three choices:
delete: Just delete the old working directory.
resume: Simply continue the previous backup from the point at which it
left off. NOTE: If the client has changed its include/exclude
configuration since the backup was interrupted, the recovery method
will automatically switch to 'delete'.
Note also that if the backup was interrupted in phase 1 (file system scan), the recovery method will automatically switch to 'delete'.
Setting 'delete' is the safest option (and also the default), because it means
that an entire backup run has to finish uninterrupted for a backup to be
considered complete. If you want to do Windows bare metal restores, you should
choose this option so that you don't end up with a mixture of files from
different VSS snapshots.
For 'resume', burp will use the working directory's original client file system scan in order to request the remaining files that it needs to finish the backup. If you are using Windows (or some other OS that similarly generates browsable file system snapshots for backing up), it will mean that files have been copied from more than one snapshot, so the restore will be inconsistent if you are considering a bare metal restore. Additionally, there are occasionally bugs reported in the resume code, which can be avoided if you use 'delete'. Personally, I use 'resume' for my backups and have had no problems.
Some people have a lot of data, and need to give an initial backup extra help
to complete. They might set 'resume' until they have that initial backup, and
switch to 'delete' after that.
Во время резервного копирования сервер создает каталог в области хранения клиента с номером и меткой времени.
Например:
/var/spool/burp/<клиент>/0000027 12.04.2015 01:24:29
На этапах резервного копирования 1 (сканирование файловой системы) и 2 (отправка фактических данных) будет указана символьная ссылкоа, указывающая на каталог под названием «working»:
/var/spool/burp/<клиент>/working -> 0000027 12.04.2015 01:24:29
На этапах резервного копирования 3 (генерация манифеста) и 4 (перетасовка) символьная ссылка будет переименована в «finishing»:
/var/spool/burp/<клиент>/finishing -> 0000027 12.04.2015 01:24:29
Когда резервное копирование будет завершено, символьная ссылка будет переименована в «current»:
/var/spool/burp/<клиент>/current -> 0000027 12.04.2015 01:24:29
Если во время резервного копирования произошла какая-либо ошибка и резервное копирование было прервано, сервер Burp должен решить, что будет дальше. Поведение того, что произойдет дальше, запускается в следующий раз, когда клиент связывается с сервером.
Если в результате прерывания осталась символьная ссылка «finishing», сервер попытается продолжить и завершить резервное копирование. Часть 4-го этапа может включать операции которые изменяют непосредственно предыдущую резервную копию (возможно, потребуется преобразовать файлы в обратные дельты), поэтому, как только она «заканчивается», Burp может только попытаться продолжить выполнение. Обратите внимание: когда резервное копирование завершается, больше никаких данных от клиента не требуется.
Если в результате прерывания осталась символическая ссылка «working», сервер проверит опцию «working_dir_recovery_method», позволяющую решить, что делать дальше.
Есть два варианта:
- 'delete': просто удалить старый рабочий каталог.
- 'resume': просто продолжить предыдущее резервное копирование с того места, где оно было прервано.
Вариант 'delete' — самый безопасный (а также вариант по умолчанию), поскольку это означает, что весь процесс резервного копирования должен продолжаться непрерывно, чтобы резервное копирование могло быть выполнено полностью.
Если вы хотите выполнить восстановление Windows на «голое железо», вам следует выбрать этот вариант, чтобы не получить смесь файлов из различных снимков VSS.
Для 'resume' burp будет использовать исходный клиентский файл рабочего каталога для сканирования системы, чтобы запросить оставшиеся файлы, которые ему необходимы для завершения резервной копии.
Если вы используете Windows (или какую-либо другую ОС, которая аналогичным образом создает доступные для просмотра снимки файловой системы для резервного копирования), это будет означать, что файлы будут скопированы из более чем одного снимка, поэтому восстановление будет несогласованным, если вы планируете восстановление на голое железо.
Кроме того, в коде 'resume' иногда обнаруживаются ошибки, которые можно избежать, если вы используете 'delete'. Разработчик для своих резервных копий использует 'resume', и у него не возникло никаких проблем.
У некоторых людей много данных, и им требуется дополнительная помощь при завершении первоначального резервного копирования. Они могут использовать «resume» до тех пор, пока не будет получена первоначальная резервная копия, и после этого переключиться на «delete».
Восстановление
https://burp.grke.org/docs/restoring.html
fwbackups
Fwbackups - GUI утилита для резервного копирования файлов по SSH.
Особенности:
- доступна любому пользователю (без root-прав)
- может выполнять резервное копирование по автоматическому расписанию или ручному запуску
- Для резервного копирования настраиваются "наборы" - "sets" ("сеты"), в которых пользователь указывает необходимые файлы и каталоги
- Копирование может выполняться в локальную папку или на SSH сервер
- Для SSH-сервера указываются - хост, порт, имя пользователя, пароль, каталог. Есть возможность протестировать соединение.
- прямое копирование или с сжатием в архив (есть возможность создать архив с двумя параметрами "время" (меньшая скорость создания)/"качество" (лучшее качество сжатия))
- количество архивных копий для сохранения (если указать 0, резервные копии будут создаваться каждый раз, если указать другое число - будет создано указанное количество дополнительных копий)
- команды, выполняемые до и после копирования (можно указать команды выполняемые до и после запуска команды копирования)
- настройка времени запуска копирования (время запуска указывается опциональными критериями или по шаблону CRON)