Linux для админа Windows 15. Резервное копирование в Linux: tar, rsync и restic

Хорошая копия — та, из которой вы уже восстанавливались. В Windows Server за копирование отвечают Windows Server Backup, robocopy и Планировщик заданий. В Linux эти роли делят небольшие программы, и схему из них собираете вы. В этой статье вы:

• решите, что на сервере копировать, а что нет;
• освоите tar (разовый архив), rsync (зеркала и снимки) и restic (шифрованные копии с историей);
• настроите копирование базы данных, запуск по расписанию и сигнал о сбое;
• проверите восстановление: без него остальное остаётся предположением.

Задача	Windows	Linux
Копия файлов и настроек сервера	Windows Server Backup, wbadmin	restic, tar
Зеркало каталога	robocopy	rsync
Запуск по расписанию	Планировщик заданий	таймер systemd
Согласованная копия работающей базы	служба теневого копирования (VSS)	выгрузка средствами СУБД
Проверка копии	пробное восстановление в другую папку	restic restore в тестовый каталог

Что нужно знать заранее

• Командная строка Linux и файловая система и права: пути, sudo, права 600.
• SSH: ключи и безопасная настройка: rsync и restic ходят на другой сервер по SSH.
• Службы и процессы: systemd, journalctl, cron: юниты и таймеры. Bash-скрипты для администратора: по ним пишется скрипт ниже.
• Резервное копирование: правило 3-2-1: три копии на двух видах носителей, одна вне площадки. Здесь инструменты, там схема.

Статья для Ubuntu 24.04 LTS: в её репозитории restic 0.16.x (в 26.04 LTS пакет новее — проверьте apt policy restic и документацию выпуска). Документация, по которой статья сверена, — для версии 0.19.1 на 04.11.2026; команды для 0.17.0 и новее помечены.

Что копировать, а что нет

Копия сервера — это не образ диска, а всё, что нельзя получить заново:

• /etc — настройки системы и служб;
• /home и /root — файлы пользователей, ключи SSH, личные скрипты;
• /srv и каталоги данных приложений (пути зависят от приложения), кроме каталогов баз /var/lib/postgresql и /var/lib/mysql: базы копируют только выгрузкой (статья про PostgreSQL и MySQL);
• /usr/local — собственные программы и скрипты;
• /var/backups/db — плановые выгрузки баз (раздел про расписание);
• список вручную установленных пакетов (apt-mark showmanual): сами пакеты скачаются заново, а список подскажет, что ставить на новом сервере.

В примерах копируется часть списка, в скрипте — весь. Не копируйте /proc и /sys (виртуальные файловые системы, данных на диске в них нет). Не нужны /run, /tmp и кэши (~/.cache, /var/cache): они воссоздаются сами.

Данные контейнеров Docker копируйте из томов и каталогов хоста, а не весь /var/lib/docker (статья про Docker).

Главная ловушка — работающие базы: файлы, скопированные во время записи, дают «рваную» копию, которая может не открыться. Поэтому сначала выгрузка средствами СУБД, затем копирование результата.

tar: разовый архив

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

В /etc лежат секреты (ключи, пароли служб), а tar не шифрует. Поэтому каталог и архив создаём закрытыми, с правами 700 и 600:

sudo install -d -m 700 /mnt/backup
sudo sh -c 'umask 077; tar -czf /mnt/backup/etc-2026-11-04.tar.gz \
  --exclude="*.tmp" -C / etc'
sudo tar -tzf /mnt/backup/etc-2026-11-04.tar.gz | head -3

Опции: -c создать архив, -z сжать gzip, -f имя файла, -C / перейти в каталог / (пути в архиве будут etc/...), -t показать содержимое, -x распаковать. Опция --exclude позиционная: её ставят до списка путей, иначе она не сработает (GNU tar сообщит has no effect и завершится с кодом 2). При распаковке от root tar по умолчанию восстанавливает права и владельцев.

Архив проверяют, достав из него файл в отдельный каталог (так советует документация Ubuntu Server):

mkdir -p /tmp/tar-test
sudo tar -xzf /mnt/backup/etc-2026-11-04.tar.gz \
  -C /tmp/tar-test etc/hostname
cat /tmp/tar-test/etc/hostname
sudo rm -r /tmp/tar-test

rsync: синхронизация и снимки по датам

rsync передаёт только различия между источником и приёмником. Он работает локально и по SSH (на обоих серверах нужен rsync). Режим -a («архивный») включает рекурсию и сохраняет права, время, владельцев и ссылки. Правило завершающего слэша (/srv/data/ копирует содержимое, /srv/data — сам каталог) разобрано в статье про SSH.

Зеркало и опция --delete

С --delete rsync удаляет у приёмника файлы, которых нет у источника, и приёмник становится точным зеркалом. Это синхронизация, а не копия: удалённый или зашифрованный файл исчезнет и из «копии». Если источник окажется пустым или не смонтированным, опустеет и приёмник. Поэтому сначала пробный запуск: -n (--dry-run) ничего не меняет, а -i показывает, что бы произошло.

sudo rsync -ain --delete /srv/data/ /mnt/mirror/data/

Пример вывода (формат приблизительный):

*deleting   old-report.txt
>f+++++++++ new-report.txt
>f.st...... prices.csv

*deleting — файл, который будет удалён из приёмника; >f+++++++++ — новый файл; >f.st...... — изменились размер и время. Убедившись, что список верен, повторите команду без -n. Страховка на случай сбоя источника — --max-delete=100: при большем числе удалений остальные rsync пропустит и завершится с кодом 25.

Снимки по датам: --link-dest

Опция --link-dest превращает rsync в простую систему версий. Файлы, не изменившиеся с предыдущей копии, в новой папке создаются как жёсткие ссылки на старые. Каждая папка с датой выглядит как полная копия, а места занимают только изменения:

sudo rsync -a --mkpath \
  --link-dest=/mnt/backup/data/2026-11-03 \
  /srv/data/ /mnt/backup/data/2026-11-04/

Путь в --link-dest пишите абсолютным: относительный отсчитывается от каталога назначения. Обе папки должны быть на одной файловой системе: жёсткая ссылка не работает между разными монтированиями. При первом запуске опцию не указывают: предыдущей папки ещё нет. Старые папки приходится удалять самим. Каталог /mnt/backup здесь учебный. Чтобы сохранялись владельцы (-o из -a), приёмный rsync должен работать от root.

restic: копии с историей и шифрованием

restic хранит копии как снимки (snapshot): состояние набора каталогов на момент копирования. Данные лежат в зашифрованном репозитории, одинаковые блоки хранятся один раз (дедупликация) и сжимаются. Своего расписания у restic нет: его запускает таймер systemd или cron.

Установка

apt policy restic
sudo apt install restic
restic version

Пароль и репозиторий

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

sudo install -d -m 700 /etc/restic
sudo sh -c 'umask 077; openssl rand -base64 32 > /etc/restic/password'
sudo ls -l /etc/restic/password
sudo cat /etc/restic/password

Последняя команда нужна один раз: скопируйте пароль в менеджер паролей. Дальше работаем в сеансе root (копировать /etc и /home нужно со всеми правами). Репозиторий и файл пароля передаём переменными окружения RESTIC_REPOSITORY и RESTIC_PASSWORD_FILE; init выполняется один раз: на существующем репозитории он не сработает.

admin-lab@lnx1:~$ sudo -i
root@lnx1:~# export RESTIC_REPOSITORY=/mnt/backup/restic-repo
root@lnx1:~# export RESTIC_PASSWORD_FILE=/etc/restic/password
root@lnx1:~# restic init

Пример вывода (идентификатор вымышленный):

created restic repository 085b3c76b9 at /mnt/backup/restic-repo

Репозиторий не должен лежать на одном диске с данными: тогда это не копия. Каталог /mnt/backup в примерах — отдельный смонтированный диск (для тренировки подойдёт и обычный каталог). SMB-шару для репозитория документация restic на Linux не рекомендует.

Первая копия и просмотр

root@lnx1:~# restic backup --one-file-system --exclude-caches \
  /etc /home /srv /srv/data

Пример вывода (числа вымышленные):

Files:           312 new,     0 changed,     0 unmodified
Dirs:            148 new,     0 changed,     0 unmodified
Added to the repository: 5.213 MiB (2.101 MiB stored)

processed 312 files, 9.021 MiB in 0:02
snapshot 40dc1520 saved

--one-file-system не даёт restic заходить в другие файловые системы (виртуальные вроде /proc в снимок не попадут); пути, указанные явно, копируются. Это касается и вложенных точек монтирования: диск /srv/data из статьи про файловую систему в снимок /srv не войдёт, и ошибки не будет, поэтому его указывают отдельным путём (нет такого диска — уберите путь). --exclude-caches пропускает каталоги с файлом CACHEDIR.TAG. Свои исключения кладут в файл и подключают опцией --exclude-file:

# /etc/restic/excludes.txt
/home/*/.cache
*.tmp
/etc/restic/password
/root/.ssh/id_ed25519_restic

Файл пароля и закрытый ключ для копий исключены: их копии хранятся отдельно. Повторите команду: restic найдёт предыдущий («родительский») снимок тех же путей и загрузит только изменения, в строке Added to the repository будет почти ноль. Посмотреть результат:

root@lnx1:~# restic snapshots
root@lnx1:~# restic ls latest | head
root@lnx1:~# restic check

snapshots перечисляет снимки, ls показывает файлы в снимке (latest — последний). check проверяет целостность структуры репозитория и должен закончиться строкой no errors were found. Чтобы проверить и сами данные, добавляют --read-data (читает всё, это долго) или --read-data-subset=10% (случайная часть). Снимок можно смонтировать как каталог командой restic mount (нужен FUSE — механизм файловых систем в пользовательском пространстве).

Хранение и очистка: forget --prune

Политика хранения описывает, сколько снимков оставить: например, 7 дневных, 4 недельных и 6 месячных. Удаление идёт в два шага: forget убирает снимки, prune освобождает место от данных, на которые ссылались только они. Опция --prune у forget соединяет оба шага.

root@lnx1:~# restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
  --dry-run
root@lnx1:~# restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
  --prune
root@lnx1:~# restic check

Для хранилища «только дозапись», которое защищает копии от шифровальщиков, нужна опция --keep-within, а очистку запускают с отдельного защищённого компьютера (см. статью про 3-2-1).

Репозиторий на другом сервере (SFTP)

Копия на том же сервере не спасёт от его гибели, поэтому репозиторий выносят на lnx2 по SFTP (передача файлов поверх SSH). Предполагается состояние стенда из врезки «Состояние стенда» в статье про Ansible: lnx2 существует, lnx1 входит на него по ключу.

Здесь схема push: lnx1 сам заходит на lnx2. В статье про 3-2-1 копию забирает lnx2 ключом, которого нет у lnx1, и взломанный lnx1 не может стереть копии. У нас ключ есть: ограничение сужает вред, но удалять файлы репозитория им можно. Ключ отдельный (не ключ администратора и не ключ Ansible) и без парольной фразы: иначе автоматическая копия невозможна.

Пользователя называем restic-backup: имя backup занято системной учётной записью Ubuntu (UID 34, оболочка nologin). Репозиторий — /srv/restic, как в статье про 3-2-1. Пароль лежит в /etc/restic/password, потому что копирует root (там он был в домашнем каталоге admin-lab); второй репозиторий в тот же каталог не создавайте. На lnx1 создайте ключ и выведите его открытую часть:

sudo install -d -m 700 /root/.ssh
sudo ssh-keygen -t ed25519 -N '' -f /root/.ssh/id_ed25519_restic
sudo cat /root/.ssh/id_ed25519_restic.pub

На lnx2 подготовьте пользователя, каталог репозитория и файл ключей:

sudo adduser --disabled-password --comment 'restic repository' restic-backup
sudo install -d -o restic-backup -g restic-backup -m 700 \
  /srv/restic /home/restic-backup/.ssh
sudo install -m 600 -o restic-backup -g restic-backup /dev/null \
  /home/restic-backup/.ssh/authorized_keys
sudo nano /home/restic-backup/.ssh/authorized_keys

В файл вставьте одну строку, подставив вместо <КЛЮЧ> вывод последней команды с lnx1:

restrict,from="192.168.10.20",command="/usr/lib/openssh/sftp-server" <КЛЮЧ>

Опция restrict отключает проброс портов, агент, X11 и терминал, from= пускает ключ только с адреса lnx1, а command= запускает вместо любой команды клиента (в том числе оболочки) только sftp-server; это действует и для подсистемы. SFTP не привязан к каталогу /srv/restic: ключ позволяет читать файлы lnx2, доступные всем пользователям; жёсткую изоляцию даёт ChrootDirectory с internal-sftp в sshd_config, но это вне рамок статьи. Путь — подсистема sftp по умолчанию в Ubuntu: сверьте со строкой Subsystem в /etc/ssh/sshd_config. На lnx1 опишите сервер в /root/.ssh/config: псевдоним lnx2-restic — удобство, он избавляет от пользователя и ключа в адресе репозитория.

Host lnx2-restic
    HostName 192.168.10.21
    User restic-backup
    IdentityFile /root/.ssh/id_ed25519_restic
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 240

ServerAlive* не дают серверу оборвать соединение, пока restic перебирает большие неизменённые данные. Проверьте вход до расписания: sudo sftp lnx2-restic (подтвердите отпечаток, введите ls и bye); команда sudo ssh -n lnx2-restic id ничего не должна напечатать: id не выполняется. Если вход не работает, исправьте или удалите строку в authorized_keys на lnx2: вход admin-lab это не затрагивает. Создайте репозиторий:

root@lnx1:~# export RESTIC_REPOSITORY=sftp:lnx2-restic:/srv/restic
root@lnx1:~# restic init

Расписание, выгрузка баз и сигнал о сбое

Соберём скрипт и таймер. Настройки таймера (OnCalendar=, Persistent=, RandomizedDelaySec=) разобраны в статье про systemd. Скрипт нужен только root, поэтому лежит в /usr/local/sbin.

Базы выгружаем в /var/backups/db: каталог закрыт (root:root, 700), restic копирует его вместе с остальным, и это работает в любой версии. Команды те же, что в статье про PostgreSQL и MySQL: PostgreSQL выгружают от имени postgres, MySQL — от root. Оставьте блок вашей СУБД (appdb — база из той статьи). Выгрузка идёт во временный файл, чтобы сбой не затёр прежнюю хорошую копию. pg_dump не сохраняет роли, поэтому рядом лежит globals.sql (в нём хеши паролей: каталог закрыт). Учётные записи MySQL в дамп одной базы не попадают: команды CREATE USER и GRANT сохраняйте отдельно, как в той статье.

sudo nano /etc/restic/excludes.txt
sudo nano /usr/local/sbin/restic-backup.sh
sudo chmod 750 /usr/local/sbin/restic-backup.sh

Содержимое скрипта:

#!/bin/bash
set -euo pipefail
umask 077

export RESTIC_REPOSITORY=sftp:lnx2-restic:/srv/restic
export RESTIC_PASSWORD_FILE=/etc/restic/password
export RESTIC_CACHE_DIR=/var/cache/restic

DUMPS=/var/backups/db
install -d -m 700 "$DUMPS"
sudo -u postgres pg_dump -Fc appdb > "$DUMPS/appdb.dump.new"
mv "$DUMPS/appdb.dump.new" "$DUMPS/appdb.dump"
sudo -u postgres pg_dumpall --globals-only > "$DUMPS/globals.sql.new"
mv "$DUMPS/globals.sql.new" "$DUMPS/globals.sql"
mysqldump --single-transaction --routines --events appdb \
  > "$DUMPS/appdb-mysql.sql.new"
mv "$DUMPS/appdb-mysql.sql.new" "$DUMPS/appdb-mysql.sql"

# Список вручную установленных пакетов попадёт в копию вместе с /etc.
apt-mark showmanual > /etc/restic/manual-packages.txt

# /srv/data — отдельный диск из статьи про файловую систему; проверка не даст
# копировать пустой каталог, если диск не смонтирован (без диска уберите
# строку проверки и путь /srv/data).
mountpoint -q /srv/data

restic backup --one-file-system --exclude-caches \
  --exclude-file=/etc/restic/excludes.txt \
  /etc /home /root /srv /srv/data /usr/local "$DUMPS"

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Адрес репозитория в скрипте — из раздела про SFTP; для локального подставьте /mnt/backup/restic-repo. Если по адресу репозитория ничего нет (например, не смонтирован диск), restic backup завершится ошибкой (в restic 0.17.0 и новее — с кодом 10, в старых — с кодом 1), а не запишет данные в пустой каталог.

С restic 0.17.0 выгрузку можно передать без файла опцией --stdin-from-command (сбой команды отменит копию); конвейер выгрузка | restic backup --stdin при сбое выгрузки создаст пустой снимок.

Теперь три юнита. Первый запускает копию. Директива OnFailure= включает указанный юнит, когда этот переходит в состояние failed:

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Backup with restic
OnFailure=restic-backup-failed.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-backup.sh

Второй — «сигнализатор». Он пишет в системный журнал запись с приоритетом crit (logger -p, метка — опция -t); %H systemd заменяет на имя узла:

# /etc/systemd/system/restic-backup-failed.service
[Unit]
Description=Report a failed restic backup

[Service]
Type=oneshot
ExecStart=/usr/bin/logger -p user.crit -t restic-backup "backup failed on %H"

Путь /usr/bin/logger подтвердите командой command -v logger. Третий — таймер:

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target

Создайте файлы через sudo nano, включите таймер, запустите копию вручную и посмотрите результат:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -n 20 --no-pager
systemctl list-timers restic-backup.timer

Проверьте и сам сигнал: временно уберите файл пароля, запустите копию (она должна упасть), найдите запись и верните файл:

sudo mv /etc/restic/password /etc/restic/password.off
sudo systemctl start restic-backup.service
sudo journalctl -p crit -t restic-backup --no-pager
sudo mv /etc/restic/password.off /etc/restic/password

Запись в журнале — лишь основа. Письмо с сервера уйдёт только при настроенной почтовой службе (отдельная тема); без неё читайте журнал или подключите внешнюю систему мониторинга, например Zabbix. У OnFailure= есть слепое пятно: если таймер отключён или не установлен либо сервер выключен надолго или вышел из строя, юнит не запустится и не упадёт, сигнала не будет (короткое выключение закрывает Persistent=true). Следите ещё и за возрастом последнего снимка.

Практика: проверка восстановления

Проверим на тестовых данных в сеансе root, где заданы RESTIC_REPOSITORY и RESTIC_PASSWORD_FILE (если сеанс закрыт, откройте его и экспортируйте переменные снова). Шаги безопасны для повторения: всё восстанавливается в отдельные каталоги, а «потерянный» файл — тестовый.

1. Создайте тестовые данные и сделайте копию:

   root@lnx1:~# mkdir -p /srv/data
   root@lnx1:~# echo 'restore test' > /srv/data/test1.txt
   root@lnx1:~# restic backup /srv/data

2. Восстановите один файл в отдельный каталог. --include ограничивает восстановление этим файлом, --target задаёт каталог назначения; файл появится по пути /tmp/restore-test/srv/data/test1.txt:

   root@lnx1:~# restic restore latest --target /tmp/restore-test \
    --include /srv/data/test1.txt
   root@lnx1:~# cat /tmp/restore-test/srv/data/test1.txt

3. Восстановите каталог целиком. Запись снимок:подкаталог (с версии 0.16.0) делает подкаталог корнем восстановления, поэтому файлы окажутся прямо в целевом каталоге. Пустой вывод diff означает, что различий нет:

   root@lnx1:~# mkdir -p /tmp/restore-data
   root@lnx1:~# restic restore latest:/srv/data --target /tmp/restore-data
   root@lnx1:~# diff -r /srv/data /tmp/restore-data

4. Имитируйте потерю: удалите тестовый файл и верните его. Поверх существующих данных restore перезаписывает файлы, поэтому в restic 0.17.0 и новее сначала пробный запуск: --dry-run --verbose=2 перечисляет, что будет сделано (если путь в выводе не тот, поправьте --include). В более старой версии пропустите первую команду restore: пробным запуском служит шаг 2.

   root@lnx1:~# rm /srv/data/test1.txt
   root@lnx1:~# restic restore latest:/srv/data --target /srv/data \
    --include /test1.txt --dry-run --verbose=2
   root@lnx1:~# restic restore latest:/srv/data --target /srv/data \
    --include /test1.txt
   root@lnx1:~# cat /srv/data/test1.txt

   Перед восстановлением поверх рабочих данных сделайте свежий backup: по документации, прерванное восстановление может оставить файлы в промежуточном состоянии.

5. Проверьте репозиторий и часть самих данных: restic check --read-data-subset=10%.

6. Проверьте отдельную копию пароля: выполните unset RESTIC_PASSWORD_FILE и restic snapshots, введите пароль из менеджера паролей вручную, затем верните переменную: export RESTIC_PASSWORD_FILE=/etc/restic/password.

7. Уберите за собой: rm -r /tmp/restore-test /tmp/restore-data, rm /srv/data/test1.txt, затем exit.

Это выборочная проверка, повторяйте её регулярно. Раз в квартал проводите полную: на тестовой виртуальной машине восстановите данные по адресу репозитория и паролю «с нуля», а выгрузки баз загрузите в тестовую СУБД (статья про базы данных). Сравните затраченное время с требуемым временем восстановления (RTO, см. статью про 3-2-1).

Типичные ошибки и недоразумения

• --delete без --dry-run. Пустой или не смонтированный источник превратит приёмник в пустой каталог. Нужны пробный запуск, --max-delete и проверка кода возврата.
• Зеркало вместо копии. rsync --delete передаёт приёмнику и удаление, и шифрование. Версии дают --link-dest или restic.
• Пользователь backup на lnx2. Он уже есть в Ubuntu как системный (оболочка nologin): заводите отдельного пользователя.
• Пароль restic есть только на копируемом сервере. Потеряете сервер — потеряете доступ к копиям. Храните копию отдельно и проверяйте её, как в практике.
• Код возврата 3 у restic backup. Снимок создан, но часть файлов не прочитана (чаще всего не хватило прав). Запускайте копию от root. Для systemd код 3 — ошибка, поэтому очистка после него не выполняется.
• «repository is already locked». После прерванного запуска может остаться блокировка: убедитесь, что другая копия не работает, и выполните restic unlock.
• Ни разу не восстанавливали. Копия есть, но из неё не восстановить: потерян пароль, пустая папка, файл не включён.

Проверьте себя

1. Чем отличаются rsync -a /srv/data /mnt/x/ и rsync -a /srv/data/ /mnt/x/? В первом случае в /mnt/x появится каталог data, во втором содержимое data окажется прямо в /mnt/x: завершающий слэш источника означает «копировать содержимое».
2. Почему rsync -a --delete не резервная копия и как безопасно проверить такую команду? Приёмник становится зеркалом источника, поэтому удалённые или зашифрованные файлы пропадают и из «копии». Сначала -n (--dry-run), для страховки --max-delete.
3. Что нужно, чтобы открыть репозиторий restic после потери сервера? Адрес репозитория и пароль: его копия хранится вне сервера, без него данные потеряны.
4. Как проверить, что копия restic действительно восстанавливается? Восстановить файлы в отдельный каталог (restic restore ... --target ...), сравнить с оригиналом, запустить restic check и записать результат.
5. Что делает OnFailure= в юните и какую ситуацию он не заметит? Он запускает указанный юнит, когда этот перешёл в состояние failed. Если таймер отключён или сервер выключен надолго, юнит не запустится и не упадёт, поэтому проверяют ещё и возраст последнего снимка.

Что дальше

• Резервное копирование: правило 3-2-1 и защита от шифровальщиков — схема копий, неизменяемые и офлайн-копии, чек-лист.
• Базы данных на Linux: PostgreSQL и MySQL — выгрузки и восстановление баз.
• Мониторинг: Prometheus, node_exporter и Grafana — графики и оповещения о состоянии серверов.
• Диски: LVM и программный RAID — почему RAID не заменяет копию и как расширять тома.

Источники

• restic: Preparing a new repository — init, пароль и его потеря, SFTP, предупреждение про CIFS.
• restic: Backing up — backup, исключения, --one-file-system, --stdin-from-command, коды возврата.
• restic: Restoring from backup — restore, --include, снимок:подкаталог, --dry-run, mount.
• restic: Removing backup snapshots — forget, prune, политика хранения, режим «только дозапись».
• restic: Working with repositories — check, --read-data, --read-data-subset.
• restic: Scripting — переменные окружения, коды возврата.
• restic: Changelog — в каких версиях появились --stdin-from-command, restore --dry-run, коды возврата 10 и 11, запись снимок:подкаталог.
• rsync(1), Ubuntu 24.04 — -a, --dry-run, --delete, --max-delete, --link-dest, --itemize-changes, коды возврата.
• tar(1), Ubuntu 24.04 — -c, -x, -t, -z, -C, -p, --numeric-owner, --exclude.
• GNU tar: Position-Sensitive Options — --exclude до списка путей, сообщение has no effect.
• Ubuntu Server: How to back up using shell scripts — tar, проверка и восстановление из архива.
• sshd(8), Ubuntu 24.04 — формат authorized_keys: restrict, command= (действует и для подсистемы).
• sshd_config(5), Ubuntu 24.04 — подсистема sftp по умолчанию в Ubuntu: /usr/lib/openssh/sftp-server.
• systemd.unit(5) — OnFailure=, спецификатор %H (systemd 255, как в 24.04).
• logger(1), Ubuntu 24.04 — опции -p и -t.