Бэкап linux по ssh

Создание бекапов удаленно используя ssh, scp, tcl. Несколько способов

Первый метод

Это баш(shell) скрипт — использует принцип удаленного беспарольного входа по ключу, используя SSH(через ssh-id). Как настроить такое соединение вы можете почитать в этой статейке

Наш первый скрипт:

BACKUPDIRS=»/home/test1 /home/test2″
TMPDIR=»/home/»
timestamp=`date «+%Y_%m_%d»`

ssh $DST_LOGIN@$DST_IPADDR ‘tar -zcvf ‘$TMPDIR$DST_IPADDR’_’$timestamp’.tar.gz ‘$BACKUPDIRS || err «Remote connection failed»
scp $DST_LOGIN@$DST_IPADDR:$$_$.tar.gz ./
ssh $DST_LOGIN@$DST_IPADDR ‘rm -f ‘$TMPDIR$DST_IPADDR’_’$timestamp’.tar.gz’ || err «Remote connection failed»

Этот скрипт коннектится по ssh к удаленному серверу, создает бекап, переписывает его на главный сервер и далее — удаляет созданный бекап на удаленном сервере.

Второй метод

Работает по такому принципу — удаленного коннекта к серверу используя язык TCL.
Его можно использовать тогда когда по каким то причинам нет возможности создать беспарольный вход(по ключу) используя SSH.
Тут уже требуются данные входа не только для удаленного сервера, но и для главного сервера, для последующего копирования бекапа на главный сервер

Наш второй скрипт:

#!/usr/bin/expect -f
set timeout 100
set SELFPASS «mypassword»
set SELFUSER «root»
set SELFIP «91.214.132.13»
set SELFDIR «/home/backup5»

set PASS «remotepassword»
set USER «root»
set IPSERV «91.214.132.14»
set BackupDirectories «/home/test1 /home/test2»
set TMPDIR «/home/backup5»

spawn ssh $USER@$IPSERV
expect «assword:»
send «$PASS\r»
expect «#»
send «tar -zcvf $TMPDIR/backup.tar.gz $BackupDirectories\r»
expect «#»
send «scp -r $TMPDIR/backup.tar.gz $SELFUSER@$SELFIP:$SELFDIR/\r»
expect <
-re «.*Are.*.*yes.*no.*» <
send «yes\r»
exp_continue
#look for the password prompt
>
«assword:» <
send «$SELFPASS\r»
#he expect command will now return
>
>

send «exit;\r»
expect eof

Этот скрипт коннектится на удаленный сервер используя язык tcl, и команду (метод) expect — метод пошагового выполнения алгоритма с ожиданием ответа с удаленного сервера. Далее создает бекап и копирует его на главный сервер используя тот же scp протокол. Этот скрип требует более скурпулезной отладки и настройки дополнительных пакетов tcl (expect) на серверах. Но все же он интересен в своем исполнении т.к. в целом показывает дополнительные возможности удаленной работы с серверами.

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

Источник

Записки программиста

Резервное копирование базы данных и файлов по SSH

Единственный 100% способ восстановить утерянные по той или иной причине данные — это иметь резервную копию. Репликация не спасет вас от случайного удаления таблицы, а RAID — от пожара в дата-центре . В этом посте я опишу, как настроить резервное копирование с помощью ssh и crond.

Как нетрудно догадаться, нам понадобятся две машины. На одной хранятся важные данные и поднят sshd (сервер), на второй имеется crond и место под хранение резервных копий (клиент).

1. Доступ к серверу без пароля

Поскольку делать backup мы будем по крону, придется настроить доступ к серверу по identity file. Заходим на сервер, и проверяем, что /etc/ssh/sshd_config не содержит строчки:

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

На стороне клиента выполняем следующую последовательность команд от имени пользователя, который будет производить резервное копирование по крону:

/ .ssh / id_rsa.pub | ssh user @ server «cat >> .ssh/authorized_keys»

Здесь мы создали пару ключей для входа на сервер по ssh и скопировали наш public-key на сервер. Делаем проверку:

Если нам удалось зайти без пароля, значит все сделано правильно. В противном случае внимательно перечитываем эту часть и ищем ошибку.

2. Скрипт резервного копирования

На машине, с моей легкой руки названной клиентом, создаем каталог, где будет хранится скрипт, запускаемый по крону, и каталог для резервных копий. Для определенности, у меня это будут

/cron-backup/backups/ соответственно. Важно убедится, что последний каталог находится в разделе, где достаточно место для хранения резервных копий.

Вот так может выглядеть скрипт резервного копирования:

#!/bin/sh
# daily-backup.sh script
# (c) Alexandr A Alexeev 2009 | http://eax.me/

# переходим в каталог, где находится скрипт
cd / home / client-user / cron-backup

# делаем резервную копию каталога на сервере
ssh user @ server \
«tar cvzf — path/to/data/abc» > \
. / backups / data-abc- ` date «+%Y-%m-%d» ` .tgz

# делаем резервную копию базы данных MySQL на сервере
ssh user @ server \
«mysqldump —defaults-extra-file=.dbname_backup db_name | gzip» > \
. / backups / db-name- ` date «+%Y-%m-%d» ` .sql.gz

# удаляем резервные копии старше одной недели
find . / backups -mtime + 7 -print -delete

Примечание: Помните, что для получения горячей копии базы данных в непротиворечивом состоянии необходимо использовать утилиту mysqldump с флагом — -lock-tables (возможно, — -lock-all-tables — см man) в случае с MyISAM или — -single-transaction в случае с InnoDB. При резервном копировании файлов может быть целесообразно создать снапшот файловой системы (см пятый пункт шестого выпуска мини-заметок).

Файл .dbname_backup на сервере должен хранить настройки подключения к базе данных db_name и иметь права доступа 600.

Меняем права доступа к нашему скрипту и проверяем его работоспособность:

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

# Мейкфайл для синхронизации файлов
# (c) 2011 Александр Алексеев | http://eax.me/

# не забываем слэши на конце!
REMOTE=user@example.ru:path/to/directory/
LOCAL=./
# кстати, при LOCAL=./ сам мейкфайл тоже синхронизируется 🙂

put:
rsync -e ssh —progress —del -zutr $ $
get:
rsync -e ssh —progress —del -zutr $ $

Для резервного копирования говорим «make get», для восстановления файлов — «make put».

3. Запуск скрипта по крону

Осталось самое простое — добавить одну строчку в /etc/crontab:

Тут важно помнить о переводе часов на летнее и зимнее время. Чтобы скрипт регулярно выполнялся ровно один раз, не стоит планировать его выполнение на период с 2-х до 3-х часов ночи включительно. Перевод часов на зимнее время отменили, так что головной боли теперь меньше. Главное — не забыть правильно настроить систему.

4. Заключение

Разумеется, здесь многое можно доработать или сделать по своему. Например, кому-то нравится говорить «crontab -e» и прописывать команды на автозапуск в локальном кронтабе пользователя вместо редактирования /etc/crontab. В daily-backup.sh можно добавить почтовые уведомления администратора системы. Файлы конфигурации могут хранится в других каталогах, в зависимости от вашей системы. В общем, не стоит следовать предложенной инструкции буквально.

Дополнение: Восстановление из бэкапа рассмотрено в статье Мой опыт переноса блога с шаред хостинга на VDS.

Источник

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

Для работы над проектами использую svn, который находится на удаленном виртуальном выделенном хосте, под управлением ubuntu 8.04. Со временем объемы данных выросли, как и критичность этих данных. Потеря чего-то снилась в кошмарах. Время от времени копировал репозитории на локальный компьютер. Недавно мне это надоело. И я стал искать возможности автоматизировать это дело. Не буду говорить о поисках и вариантах, расскажу о результатах.

Итак, мы имеем удаленный хост под управлением ubuntu, с некоторым массивом довольно критичных данных. Довольно логичным было бы настроить бэкап прямо на удаленном хосте, с помощью tar по крону, rsyns и т.д. Но, т.к. место на виртуальном выделенном хостинге довольно дорого и использовать его лучше по делу, идеально было бы, чтобы данные автоматически копировались на какую нибудь локальную машину, место на которой хоть отбавляй. В моем случае это файловый сервис в офисе, под управлением все той же Ubuntu.

Подготовка

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

$ ssh-keygen -t dsa

Оставьте папку по-умолчанию, а пароль сделайте пустым.
Эта команда должна создать в папке

/.ssh(по умолчанию) два файла — private и public key. private предназначается для локальной машины, pub отправляется на удаленный.

Теперь копируем private key в папку /root/.ssh, чтобы пользователь root так мог пользоваться им

/.ssh
$ sudo mkdir /root/.ssh
$ sudo cp id_dsa /root/.ssh

Теперь надо скопировать public key на удаленную машину, с которой мы хотим копировать данные. Предварительно создайте пользователя backup на удаленной машине(команда adduser). Не забудьте дать этому пользователю права на чтение каталогов, которые вы хотите копировать.

/.ssh/id_dsa.pub | ssh backup@remotehost.ru «cat >>

Теперь можем попробывать зайти через ssh на удаленную машину:

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

remotehostru$ chmod 700 .ssh
remotehostru$ chmod 400 .ssh/authorized_keys2
remotehostru$ exit

Настройка rsnapshot

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

Установка

$ sudo apt-get install rsnapshot

Если вы используете не debian-подобный дистрибутив, rsnapshot наверняка тоже есть в репозиториях вашего дистрибутива. Для CentOS, при включенных RPMForge это делается, например, так:

# yum install rsnapshot

Теперь нам нужно создать директорию, где мы собираемся хранить наши «снимки»:

$ sudo mkdir /var/snapshots

Настройка

Теперь можно перейти к настройке, собственно, rsnapshot:

$ sudo nano /etc/rsnapshot.conf

Вместо nano вы можете использовать любой другой редактор, например vi, или gedit, если работаете в GNOME.
Настроить нужно следующие параметры:

snapshot_root — директория, в которую вы хотите сохранять «снимки».

interval xxx yy — ххх — название интервала(например hourly, daily), yy — количество снимков для каждого. Например:
interval hourly 6
interval daily 7

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

Расскомментируйте cmd_cp. cmd_ssh расскоментируйте и измените на

Настройка бэкапа осуществляется командой backup :

#Добавляем папку /etc/ с локальной машины в папку localhost/
backup /etc/ local/
#Добавляем папку /var/svn с удаленной машины в папку remotehost/
backup backup@remotehost.ru:/var/svn/ remotehost/

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

Пробный запуск

Запустим rsnapshot:
$ rsnapshot hourly

Второй параметр означает интервал, который мы задали в конфигурационном файле.
Команда может выполняется продолжительное время. После выполнения, смотрим, что она создала:
$ ls -l /var/snapshots

Пока что в директории должен быть один каталог: hourly.0. При следующем запуске rsnapshot будет создавать каталоги hourly.1, hourly.2 и т.д., пока не упрется в максимум, указанный нами в конфигурационном файле.

Настройка cron

В Ubuntu автоматически создается файл /etc/cron.d/rsnapshot со следующим содержанием:
0 */4 * * * root /usr/bin/rsnapshot hourly
30 3 * * * root /usr/bin/rsnapshot daily
0 3 * * 1 root /usr/bin/rsnapshot weekly
30 2 1 * * root /usr/bin/rsnapshot monthly

Вот и все. Теперь у вас 6 раз в сутки должен автоматически создаваться снимок данных с вашего удаленного сервера. Данные в сохранности, да еще и географически распределены.

Кстати, 6 раз в сутки не означает, что размер будет в 6 раз больше, чем если копировать всего 1 раз в сутки. Если в промежутки между копированиями не будет изменений в файлах, то общий размер копий почти не изменится.

Дополнительная информация

С помощью параметра backup_script можно также настроить резервное копирование баз данных MySQL, да и вообще всего, чего угодно. Я не описывал сей процесс, т.к. у меня он не используется и ничего конкретного сказать не могу.
Подробнее можно почитать в гугле. По запросу rsnapshot вылезает куча релевантных ссылок, правда на английском языке.

Прошу особо не ругать, на гуру администрирования(да и linux) я не похож, но довольно долго искал, как просто автоматизировать резервное копирование — нашел способ, решил поделиться.
Но конструктивной критике и предложениям буду, конечно, рад.
UPD: Эта же статья в моем блоге

Источник

Бэкап файловой системы по ssh

Получил нахаляву виртуальный сервер на vscale.io. Задача 1 — как сделать бэкап файловой системы виртуального сервера по ssh? Как потом делать восстановление из такого бэкапа?

А как tar будет бэкапить логи и прочие файлы, открытые на данный момент для записи? И как делать потом восстановление из такого бэкапа на живой системе, чтобы откатить её назад?

да, самое ж главное

Бекапить всю фс — бессмысленно. Делать бекапы нужно только полезной информации. Все остальное должно легко переустанавливаться заново с какого-то конфига установки системы

Это оффтоп. Про халяву нужно спрашивать тут Инвайты (3)

бэкап файловой системы виртуального сервера по ssh

Rsnapshot. Восстановление через копирование

Бекапить всю фс — бессмысленно. Делать бекапы нужно только полезной информации. Все остальное должно легко переустанавливаться заново с какого-то конфига установки системы

Это виртуальный сервер, для работы используется KVM-виртуализация., устанавливается система из образа. Допустим в процессе работы я решил совершить действие, в котором я сомневаюсь, установить несколько программ, например, и я делаю бэкап. Потом что-то идёт не так и я решаю откатиться на момент создания бэкапа. Как это сделать? cp и tar не подходят, потому что нужно чтобы не только содержимое ключевых файлов было возвращено к изначальному виду, но и исчезли файлы, которых ранее не было.

А снепшотов тебе нахаляву к этой машине не отсыпали? Даже в самом дешевом хецнере можно делать.

нужно чтобы не только содержимое ключевых файлов было возвращено к изначальному виду, но и исчезли файлы, которых ранее не было

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

А как tar будет бэкапить логи и прочие файлы, открытые на данный момент для записи?

делать потом восстановление из такого бэкапа на живой системе, чтобы откатить её назад?

для работы используется KVM-виртуализация., устанавливается система из образа. Допустим в процессе работы я решил совершить действие, в котором я сомневаюсь, установить несколько программ, например, и я делаю бэкап. Потом что-то идёт не так и я решаю откатиться на момент создания бэкапа. Как это сделать? cp и tar не подходят, потому что нужно чтобы не только содержимое ключевых файлов было возвращено к изначальному виду, но и исчезли файлы, которых ранее не было.

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

rsync

Как потом делать восстановление из такого бэкапа?

Хм. Тебе чтоли дают доступ в xen-консоль? Какая виртуализацию у них?

• бэкап данных, настроек
• все накрылось
• разворачиваешь бэкап

Следи за файлами типа /etc/fstab, где используются UUID’ы. /etc/passwd, по мимо файла надо еще диры создавать если не пробэкапил. Не лучший план, но по крайне мере не зависит от того, съедишь ты на другой хостинг или останешься на этом. На другом хостинге возможно не дадут возможность лить свои образы с ОС.

В этой стране это никто не умеет делать. Даже когда у них в распоряжении vmware. А почему? А потому диски под бэкапы в стоимость услуги не включили.

Потом что-то идёт не так и я решаю откатиться на момент создания бэкапа. Как это сделать?

Купить vmware workstation и играться на локалхосте. Серьезно.

Без поддержки со стороны хостера любой путь решения твоей проблемы будет через реинстал ОС на 20-30 минут и накатом твоего бэкапа. И это если еще инет быстрый и хостер не режет полосу. В противном случае твой роллбэк затянется на час-два. Если тебя такой вариант устраивает, то можешь сделать скрипт по ребуту, который делает бэкап (все процессы поостанавливаются, все хэндлеры позакрываются и простой на несколько минут, может час). После этого ОС загружается, запускается демоны, открываются логи и ты сливаешь бэкап себе.

да епт. кто мешает морозить ФС xfs_freeze и делать dump (dump умеет по ssh)

Да ты че? Вот прямо таки ONLY?

qcow2 snapshot уже отменили?

И как делать потом восстановление из такого бэкапа на живой системе, чтобы откатить её назад?

На виртуальном сервере? Да никак, в лучшем случае делай lvm snapshot с него и откатишься (lvconvert —merge, и да merge это откат назад)

ZFS тут каким боком советуют не понятно, на lvm или loop-device строить zpool что-ли? Ах, да, это же свидетли zfs, фанатики.

И? man xfs_freeze

окромя xfs она умеет морозить btrfs, ext3, and ext4

ОЙ МА, когда энто qcow2 стало ФС?

xfs_freeze ext3/ext4 и dump/restore — бекапь наживую.

Ну нахера вот дампить ФС, если rsync-ом бэкап сделать можно? Ты б еще dd в качестве решения предложил.

А как tar будет бэкапить логи и прочие файлы, открытые на данный момент для записи?

когда она примонтирована r/o

И как делать потом восстановление из такого бэкапа на живой системе

кури btrfs snapshots, стильно, модно, молодежно.

встречный вопрос нахера синькать фс когда задампить можно? Да синькать живую ось энто сильно!

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

Одна из задач, которую должен уметь делать админ — это бэкапы. Меня правда многим вещам не учили, приходится до всего доходить самому, так что то, что мои вопросы звучат для кого-то странно я не удивляюсь.
В своё время уже задавался вопросом как сделать бэкап корневого раздела, вот тема моя на юниксфоруме до сих пор жива http://unixforum.org/index.php?showtopic=131179
С тех пор пользуюсь dump/restore. Хотя и про rsync, который тут упомянался тоже слышал. На локальном сервере бэкап я делую так:

Чтобы сделать роллбэк, гружусь с Live CD, форматирую раздел и на него уже делаю restore.

Однако с удалённым и к тому же виртуальным сервером такой способ не прокатит потому что тут невозможно загрузиться с Live CD. Мне сервер достался нахаляву, но vscale.io сам по себе сервис копеечный и набор услуг у него копеечный: нет ни снапшотов, ни vnc-доступа, в панели управления сервером есть только 2 кнопки: «перезагрузить сервер» и «переустановить сервер». То есть для роллбэка я деляю переустановку (уничтожаются все данные), а потом по ssh накатываю сверху свой бэкап. Про это вроде говорили:

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

Но мне бы хотелось углубиться в теорию. По какому принципу вообще работают dump и rsync? Вот перед тем как сделать restore я создаю файловую систему на диске, сама restore файловую систему не создаёт. А значит dump/restore работает не на уровне файловой системы, а на уровне отдельных файлов и принцип их работы в общем случае ничем не отличается от принципа работы простых утилит для работы с файлами: tar и cp. А если уж я бэкаплю на файловом уровне, то я должен сначала:
1. Если у меня открыты бд я должен заставить их сбросить кэш на диск.
2. Перемонтировать корневую фс в r/o.
3. Уже после этого делать бэкап причём передавать его сразу по ssh, на диск сохранить будет невозможно, поскольку он в r/o.
Буду признателен тому кто объяснить мне как эти три пункта выполняются.

Сбрасывать кеши БД на диск смысла нет, если вы планируете переводить ФС в ro, то нужно просто останавливать (килять) все службы, пишушие на диск — базы данных, логи, почтовый сервер и т.д. Грубо говоря всё, кроме sshd.

А потом, любая команда и поток в ssh, типа

cat file.txt | ssh any.host «cat > out.file»

Такой конвеер перенаправит содержимое файла file.txt на stdin команды cat, пишущей в файл out.file на хосте any.host. И с этим можно потренироваться отдельно, без задачи бэкапа.

Что касается восстановления, то нужно потренироваться переносить корень в tmpfs (ОЗУ), через создание там рабочего chroot окружения, можно просто копирую, можно busybox + sshd, монтирования туда /dev, /proc, /sys и pivot_root (естественно, покиляв все ненужные процессы). Тогда у вас реальная корневая ФС полностью свободна и делайте с ней что угодно.

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

Поправка: у vscale.io нельзя. Некоторые дают возможность грузить любой iso.

Но мне бы хотелось углубиться в теорию. По какому принципу вообще работают dump и rsync?

dump может бэкапировать либо файлы, либо файловую систему. В вашем случае происходит копирование файловой системы с учетом i-nodes. Поэтому важно, чтобы файловая система поддерживалась утилитой dump . Напротив, rsync копирует файлы вне зависимости от типа файловой системы, главное чтобы их можно было прочитать и записать через вызовы read(2) , write(2) .

Рассмотрим минусы каждого из подходов. Минусом dump , в контексте использования, является необходимость, чтобы файловая система была размонтирована в момент бэкапа, а также, чтобы в момент восстановления подготовлен отформатированный раздел. Для контраста, утилита dd не зависит от файловой системы и использует блочное копирование, поэтому для ее работы достаточно размонтированный раздел/диск. Т.о. такой вид бэкапа подходит для систем, где есть возможность остановить все сервисы, остановить почти все службы, чтобы не производились никакие дисковые операции.

Минусом rsync является скорость работы. Поэтому он подходит для систем, где важно, чтобы никакие службы в момент бэкапирования не останавливались.

А значит dump/restore работает не на уровне файловой системы, а на уровне отдельных файлов и принцип их работы в общем случае ничем не отличается от принципа работы простых утилит для работы с файлами: tar и cp

Утилита dump в режиме инкрементального бэкапа позволяет удалять файлы на целевом носителе при восстановлении данных. Допустим вы делаете полный бэкап (опция 0), и файл /usr/local/bin/apache будет восстановлен на целевом носителе. Далее, вы решили этот файл удалить, сделали инкрементальный бэкап и восстановили его. После восстановления файла /usr/local/bin/apache вы не найдете, т.к. соответствующие записи на файловой системе были изменены. Этого поведения вы не сможете достичь используя только tar и cp . Однако утилита rsync позволяет это сделать, т.о. воссоздать точную копию на текущий момент.

1. Если у меня открыты бд я должен заставить их сбросить кэш на диск.

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

В современных системах она всегда замонтированна в ro. Вопрос в разбивке диска.

3. Уже после этого делать бэкап причём передавать его сразу по ssh, на диск сохранить будет невозможно, поскольку он в r/o.

Опять же, вопрос разбивки диска.

Суммируя все вышесказанное. Для вашего VPS подойдет подход dump/restore (или dd), если вы (или хостер) грамотно разбили диск перед установкой ОС. В 95% случаев оказывается, что имеется максимум 2-4 раздела: под корень, под /home, /tmp, и swap. Вместо классической схемы: /, /usr, /var, /tmp, /var/tmp, /home. Не нужно сейчас сломя голову бежать переустанавливать систему, раз вы поняли в чем смысл. Современные линуксы (дистрибутив вы не указали) ушли от этих стандартов, в пользу того, что проще установить систему с нуля, и восстановить только нужные данные.

Тем не менее, даже с учетом всего выше сказанного, вы можете делать бэкапы через dump/restore, как вам привычно, не забывая, что надо останавливать сервисы и службы и монтировать корневой раздел в read-only.

А можете воспользовать rsync, который на лету будет копировать только действительно нужные данные. Еще раз повторю, что в случае сложного ПО, такого как БД, ни один стандратный способ бэкапирования не предоставляет гарантий создания рабочих бэкапов, когда БД работает в штатном режиме. Используйте средства БД, если они есть.

Теперь без гаданий на кофейной гуще. Конкретно по пунктам. Ответьте на вопросы ниже:

• Можно останавливать сервисы в любой момент на время необходимое для бэкапа? Время вариируются до часа-двух.
• Имеется ли достаточно свободного места, чтобы уместить полный бэкап всей системы?

Если ответы на оба вопроса положительные, то используйте dump/restore. В противном случае подходит rsync/tar/cp и т.п.

• У меня быстрый интернет и он работает без разрывов?

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

Следующие вопросы о необходимости снимать бэкап всего:

• Мои действия несут разрушительный характер всей системе?
  • Да, я это знаю наверняка.
  • Да, но я не уверен.
• Мои действия это песочница, где я играю как хочу?

100% положительный ответ на первый вопрос означает, что вы действительно подготовленный специалист и вопрос о бэкапах был задан вами в шутку. Неуверенный ответ говорит о том, что следует углубиться в вопросы того, что вы делаете. Выше было высказывание, что вы устанавливаете пакеты и опасаетесь что-то сломать. Пакетный менеджер в своей работе использует небольшое кол-во файлов, которые в 99% случаев очень просто контролировать и для этого не нужны полные бэкапы.

Положительный ответ на второй вопрос означает, что либо вы не знаете для чего нужны VPS (в шутку про ваш случай, дуракам везет), либо вы профессионал и знаете, что делаете. Идем дальше.

• Я просто хочу, чтобы все было просто, быстро, надежно?

Все сразу не бывает. Чтобы я сделал на вашем месте?

• Определился с критичностью запущенных программ. Могу я их останавливать на любой срок или нет? Если нет, добавил варианты, когда это все же возможно
• Определился с тем, что я хочу сделать
• Изучил возможные последствия моих действий (через тестовый стенд или хотя бы прочитал документацию)
• Оценил возможности окружения (медленный интернет, (не-)возможность хранить все бэкапы на сервере)
• Составил план действий
• Подобрал инструменты
• Протестировал их работоспособность

С учетом моего опыта и познаний, в большинстве случаев я выбираю rsync, либо tar. Почему?

• Я знаю, что делаю в большинстве случаев
• В большинстве случаев мне не нужен бэкап всего раздела
• Я на лету восстанавливаю файлы конфигураций
• Пакетный менеджер умеет удалять все ненужные мне файлы, а за своими файлами мне достачно команды find > filelist
• В случае БД я делаю горячие бэкапы средствами БД
• В случае восстановления с нуля всей ОС уже имеется список всех ранее установленных програм
• В момент восстановления система будет иметь те же заголовочные и библиотечные файлы, потому что я часто обновляюсь
• Поэтому не страшно собрать программы в ручную, если это потребуется. А это не потребуется в 50% случаев
• Восстановление системы это нештатная ситуация и я стараюсь ее предотвратить, а не использовать ее в своих играх
• Для игр и стенда есть виртуалки на локалхосте
• Время восстановления системы стоит на последнем месте и я не тороплюсь
• Для песочниц в онлайн я выбираю облачные решения для своих задач
• Когда этого недостаточно я арендую физические сервера

Источник