Резервное копирование NAS на storage VPS

Как выглядит резервное копирование NAS на storage VPS

Для резервного копирования NAS на storage VPS на стороне сервера требуются четыре компонента: непривилегированный пользователь, SSH-ключ с доступом только к одному репозиторию, программа для резервного копирования, которая хранит версии, а не зеркальную копию, и расписание, сохраняющееся после перезагрузки. Настройка занимает около половины дня. Часть, которая требует недели — это первая полная копия, так как скорость исходящего соединения в домашних или малых офисных сетях значительно ниже входящей.

Данное руководство предполагает конфигурацию, которая встречается на практике: Synology или QNAP с несколькими терабайтами данных, подключенные через асимметричный VDSL или кабельный канал в доме или небольшом офисе, где требуется хранить одну копию данных вне здания. Сравнение storage VPS и домашнего NAS поможет определить, нужен ли вам VPS в принципе. Это руководство исходит из того, что он вам нужен, и описывает процесс настройки.

Сначала определимся с термином. Репозиторий — это директория на VPS, которой управляет ваша программа для резервного копирования. В ней хранятся дедуплицированные и зашифрованные блоки данных, а не копия файлов, доступная для просмотра. Вы не сможете открыть её через файловый менеджер, и в этом суть: VPS хранит данные, которые не может прочитать.

Storage VPS или управляемое хранилище

Управляемое хранилище, то есть дисковое пространство, продаваемое терабайтами и доступное по протоколам SFTP, rsync, SMB или WebDAV, — это стандартное решение, знакомое многим читателям. Его достаточно для использования в качестве простого целевого узла rsync или для задач Hyper Backup. Однако оно не предоставляет доступ к оболочке (shell), поэтому удалённая сторона может только хранить байты данных.

Наличие прав root на Storage VPS меняет возможности удалённой стороны:

• Серверная часть программы резервного копирования выполняется непосредственно там. borg serve считывает индекс репозитория на VPS и локально отвечает на вопрос «есть ли у тебя уже этот блок», поэтому по сети передаются только новые блоки данных. При использовании обычного SFTP-монтирования тот же запрос превращается в тысячи мелких сетевых операций с задержкой от 15 до 30 мс, и процесс замедляется до минимума, даже если изменилось совсем немного данных.
• Политика «только добавление» (append-only) принудительно применяется на сервере, где скомпрометированное NAS-устройство не сможет её отключить.
• Ротация (retention) выполняется с использованием диска и процессора самого VPS по выбранному вами расписанию.
• Проверка целостности также выполняется там, поэтому еженедельная проверка репозитория не потребляет пропускную способность сети.

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

Два способа выгрузки данных с NAS

Собственное задание производителя. Synology Hyper Backup и QNAP Hybrid Backup Sync работают с rsync-совместимым сервером по протоколу SSH. На VPS не нужно устанавливать ничего, кроме SSH-аккаунта и бинарного файла rsync. Вы настраиваете расписание в веб-интерфейсе, и задача автоматически возобновляется после разрыва соединения. Формат репозитория принадлежит производителю, поэтому для восстановления данных потребуется его фирменная утилита. Для домашнего использования, когда нужна удаленная копия без работы в командной строке, это оптимальный вариант.

Использование Borg или restic для записи в репозиторий на VPS. Этот метод обеспечивает дедупликацию всех версий, шифрование на стороне клиента и политику хранения, задаваемую одной командой. Для работы требуется среда исполнения: Container Manager на x86-устройствах Synology, Container Station на QNAP или небольшой постоянно включенный Linux-сервер, к которому подключены сетевые папки. Запуск с другой машины по протоколу SMB также возможен, но вы теряете метаданные владельца и ACL (списки контроля доступа), а сканирование файлов значительно замедляется, так как проверка размера и времени изменения каждого файла превращается в сетевой запрос. Выбор между restic и Borg зависит от того, где вы хотите разместить логику репозитория и как планируете выполнять очистку; оба инструмента подходят для этой задачи.

Обычный rsync -a --delete на VPS создает зеркало. Если вы случайно удалите папку в понедельник, зеркало удалит её во вторник. Программы-вымогатели, шифрующие данные на NAS, при следующем запуске перезапишут хорошие данные зашифрованными. В статье Почему вторая копия не является полноценной резервной копией подробно разбираются подобные сценарии. Краткий вывод: вам нужны версионность и ключ с доступом только на добавление (append-only), настройка которых описана в остальной части этого руководства.

Настройка пользователя для резервного копирования на VPS

Эти команды предназначены для Ubuntu 24.04 на VPS. Выполняйте их от имени обычного пользователя с правами sudo.

sudo apt update && sudo apt install -y borgbackup
sudo adduser --disabled-password --gecos "" nasbackup
sudo install -d -m 700 -o nasbackup -g nasbackup /home/nasbackup/.ssh
sudo install -d -m 755 -o root -g root /srv/borg
sudo install -d -m 700 -o nasbackup -g nasbackup /srv/borg/nas1
borg --version

--disabled-password означает, что у учетной записи нет пароля, который можно подобрать, поэтому ключ — единственный способ входа. Обратите внимание на выведенную версию. Версия Borg на NAS должна совпадать по мажорному номеру с версией Borg на VPS, так как клиент 1.x не может взаимодействовать с borg serve 2.x, и это несоответствие обнаруживается при первом подключении, а не во время установки.

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

ssh-keygen -t ed25519 -f /root/.ssh/nas_offsite -N "" -C "nas1 offsite backup"

Отсутствие парольной фразы выбрано намеренно, так как автоматизированное ночное задание не сможет её ввести. Именно поэтому важен следующий шаг: ключ должен быть бесполезен везде, кроме этого конкретного репозитория. Добавьте открытый ключ в /home/nasbackup/.ssh/authorized_keys на VPS одной строкой.

command="borg serve --restrict-to-repository /srv/borg/nas1",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... nas1 offsite backup

Затем выполните sudo chown nasbackup:nasbackup /home/nasbackup/.ssh/authorized_keys и sudo chmod 600 для этого файла. command= заменяет любую команду, которую запрашивает клиент, поэтому этот ключ не может получить доступ к оболочке (shell), запустить rsync или обратиться к любому другому пути на сервере. restrict отключает перенаправление портов, перенаправление агента, X11 и выделение pty одной командой (OpenSSH 7.2 и новее). --restrict-to-repository — это часть реализации той же идеи со стороны Borg.

Проверьте настройку с NAS:

ssh -i /root/.ssh/nas_offsite nasbackup@vps.example.com

Вы должны увидеть PTY allocation request failed on channel 0, что означает успешную работу restrict, а затем сессия зависнет без приглашения командной строки, так как borg serve ожидает протокол Borg на стандартном вводе. Нажмите Ctrl-C. Запрос пароля означает, что ключ не был установлен. Permission denied (publickey). обычно указывает на то, что права доступа к .ssh или authorized_keys слишком открыты, и sshd отказывается использовать файл, доступный для записи группе.

Теперь создайте репозиторий с NAS:

export BORG_REPO=ssh://nasbackup@vps.example.com/srv/borg/nas1
export BORG_RSH="ssh -i /root/.ssh/nas_offsite -o ServerAliveInterval=30"
borg init --encryption=keyfile-blake2
borg key export :: /root/nas1-borg-key.txt

keyfile-blake2 хранит ключ шифрования на NAS в /root/.config/borg/keys/, поэтому на VPS находятся только зашифрованные данные без ключевого материала. Риск реален: если вы потеряете NAS вместе с ключом, репозиторий станет нечитаемым навсегда. Экспортируйте ключ сразу после создания и сохраните его там, где ни одна из машин не сможет его достать, а парольную фразу запишите в менеджер паролей. borg key export --paper создает версию, которую можно распечатать. Другой вариант, repokey-blake2, хранит зашифрованный ключ внутри репозитория, что упрощает восстановление, но безопасность ограничивается стойкостью вашей парольной фразы. Защита от утечки данных с арендованного диска охватывает более широкий вопрос о том, что может видеть хостинг-провайдер.

Когда borg init и первое резервное копирование пройдут успешно, вернитесь на VPS и добавьте --append-only к принудительной команде в authorized_keys. В режиме только для добавления (append-only) сервер никогда не удаляет данные: borg delete или borg prune, отправленные через этот ключ, сообщат клиенту об успехе, в то время как сегменты останутся на диске. Таким образом, злоумышленник, получивший доступ к NAS, не сможет стереть вашу историю. Обратная сторона в том, что реальная очистка должна выполняться иначе. Запустите borg prune с машины, отличной от NAS, используя второй ключ без этого флага, либо удаляйте старые архивы вручную несколько раз в год. В любом случае, borg compact выполняется в оболочке на VPS для фактического освобождения места.

Для restic ограничение реализуется через блок sshd, а не через принудительную команду, так как restic использует SFTP:

Match User nasbackup
    ChrootDirectory /srv/restic
    ForceCommand internal-sftp
    AllowTcpForwarding no

ChrootDirectory требует, чтобы владельцем /srv/restic был root, и никто другой не имел прав на запись, а репозиторий находился в подкаталоге, владельцем которого является nasbackup. Внутри chroot путь выглядит как /nas1, а не /srv/restic/nas1, поэтому строка репозитория имеет вид sftp:nasbackup@vps.example.com:/nas1. Проверьте конфигурацию перед перезагрузкой, так как некорректный блок Match заблокирует доступ всем: sudo sshd -t && sudo systemctl reload ssh. Режим только для добавления в restic реализован в его REST-сервере (rest-server --append-only), что является причиной использовать его вместо SFTP, если вы опасаетесь программ-вымогателей на NAS.

Первое резервное копирование и что исключить

borg create --stats --progress \\
  --compression auto,zstd,3 \\
  --exclude '/volume1/*/@eaDir' \\
  --exclude '/volume1/*/#recycle' \\
  --exclude-caches \\
  ::'nas1-{now:%Y-%m-%d}' /volume1/documents /volume1/photo

auto,zstd,3 указывает Borg проверять каждый блок и пропускать сжатие там, где оно неэффективно, что характерно для большинства библиотек фото и видео. @eaDir содержит эскизы и индексные данные Synology, а #recycle — сетевую корзину: оба этих элемента можно восстановить заново, а в большой библиотеке фотографий только @eaDir может занимать десятки гигабайт трафика, который не нужно передавать. --exclude-caches пропускает каталоги, помеченные CACHEDIR.TAG.

Начните с данных, потеря которых будет критичной, а не со всего подряд. Сначала документы и фотографии, медиабиблиотеку — позже. Borg выполняет дедупликацию относительно уже сохраненных данных, поэтому последующее расширение списка включения приведет к загрузке только тех блоков, которых еще нет в репозитории. Поэтапный подход не приводит к лишним затратам ресурсов.

Сколько времени занимает первое полное копирование?

Выполните этот расчет перед началом работы, так как ответ влияет на планирование. Разделите скорость исходящего канала в мегабитах в секунду на 8, чтобы получить мегабайты в секунду. Возьмите около 90 процентов от этого значения для учета накладных расходов TCP, SSH и протокола. Затем разделите объем данных на полученное число, а результат в секундах разделите на 86,400, чтобы получить количество дней.

Следите за единицами измерения. Скорость линии измеряется в десятичных единицах, поэтому 2 TB здесь означает 2,000,000 мегабайт. NAS, который сообщает о 2 TiB данных, содержит около 2.2 TB в этих единицах, что на 10 процентов больше объема загрузки, чем вы планировали.

[
  {
    "label": "VDSL 50/10",
    "mb_per_sec_up": 1.1,
    "mb_per_sec_down": 5.6,
    "full_copy_up": "21 days",
    "full_restore_down": "4.1 days"
  },
  {
    "label": "Cable 250/25",
    "mb_per_sec_up": 2.8,
    "mb_per_sec_down": 28.1,
    "full_copy_up": "8.3 days",
    "full_restore_down": "19.8 hours"
  },
  {
    "label": "VDSL 250/40",
    "mb_per_sec_up": 4.5,
    "mb_per_sec_down": 28.1,
    "full_copy_up": "5.1 days",
    "full_restore_down": "19.8 hours"
  },
  {
    "label": "Fibre 500/100",
    "mb_per_sec_up": 11.2,
    "mb_per_sec_down": 56.2,
    "full_copy_up": "2.1 days",
    "full_restore_down": "9.9 hours"
  }
]

Эти строки представляют собой формулу, примененную к 4 типичным опубликованным тарифным планам, а не замеры реальной линии. На тарифе VDSL 50/10, который является обычным начальным уровнем, первое копирование 2 TB занимает 21 days при загрузке на полной скорости, день и ночь. На тарифе Fibre 500/100 то же самое копирование занимает 2.1 days. Кабельное соединение — это неудобный средний вариант: Cable 250/25 дает вам 2.8 мегабайт в секунду на отдачу, поэтому копирование займет 8.3 days, даже если та же самая линия позволяет загрузить весь репозиторий обратно за 19.8 hours.

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

Если первое копирование не укладывается в приемлемые для вас сроки, существуют следующие честные варианты:

• Сначала создайте резервные копии небольших и важных наборов данных, а затем расширяйте список включения в течение нескольких недель.
• Выполните первое копирование с более быстрой линии. Скопируйте данные на USB-диск, отнесите его в офис или к другу с оптоволоконным соединением и запустите там первое borg create для того же репозитория. Borg перестраивает свой локальный кэш, когда видит репозиторий с новой машины, а измененные пути означают, что файлы будут прочитаны снова, но блоки, уже имеющиеся в репозитории, не будут загружены дважды.
• Позвольте процессу работать в течение месяца с ограниченной скоростью. Это вполне допустимый выбор для домашнего использования. Четко определите, какие данные еще не защищены, так как удаленная копия не существует до завершения процесса.
• Подумайте, нужно ли вообще хранить медиатеку за пределами локальной сети. Коллекция фильмов, которую можно восстановить, не относится к той же категории, что и единственная копия счетов за пять лет, и исключение таких данных может сократить шесть недель до двух дней.

Поддержание работоспособности домашнего канала связи во время работы

Резервное копирование, которое полностью загружает исходящий канал, делает работу всей сети невозможной, включая загрузку данных. Причина кроется в очередях пакетов. Модем принимает пакеты быстрее, чем линия успевает их передавать, его буфер заполняется данными резервной копии, и каждый интерактивный пакет, каждый DNS-запрос и каждое подтверждение TCP вынуждены ждать своей очереди. Время отклика (ping) возрастает с 15 мс до нескольких сотен. Это явление называется bufferbloat; именно из-за него видеозвонок прерывается во время выгрузки данных, которая, казалось бы, использует только «свободную» емкость канала.

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

borg create --upload-ratelimit 900 ...
restic --limit-upload 900 backup ...
rsync --bwlimit=900 ...

900 KiB/s — это примерно 7.4 Mbit/s, что оставляет около 2.5 Mbit/s свободными на исходящем канале 10 Mbit/s. Измеряйте результат, а не полагайтесь на настройки. Запустите резервное копирование, затем выполните ping -c 20 1.1.1.1 с ноутбука. Если задержка близка к значению в режиме простоя, значит, лимит выбран верно. Задержка в сотни миллисекунд означает, что буфер всё ещё переполняется, поэтому уменьшите лимит на треть и повторите измерение. Маршрутизатор с современной системой управления очередями (fq_codel или cake, в некоторых прошивках обозначается как SQM) решает эту проблему корректно, так как сигнализирует о перегрузке до того, как буфер заполнится.

Настройте расписание задачи с помощью systemd timer на машине с Linux:

[Unit]
Description=Nightly offsite backup of the NAS

[Timer]
OnCalendar=*-*-* 01:30:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target

Параметр Persistent=true запускает пропущенную задачу после загрузки системы, что важно для устройств, которые не работают круглосуточно. RandomizedDelaySec распределяет время запуска, чтобы две машины не обращались к репозиторию в одну и ту же секунду и не конфликтовали из-за блокировки. Включите таймер с помощью sudo systemctl enable --now nas-offsite.timer, затем проверьте systemctl list-timers nas-offsite.timer, которая выводит время следующего запуска и результат последнего. В DSM и QTS нет systemd, поэтому там задачу вызывает встроенный планировщик задач производителя. Храните команды в одном shell-скрипте, чтобы оба способа запуска использовали идентичный код.

При обрыве соединения во время передачи

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

Borg по умолчанию создает архив контрольной точки каждые 30 минут (--checkpoint-interval 1800). После прерванного выполнения вы увидите архив, имя которого заканчивается на .checkpoint. Следующая команда borg create заново считывает исходные файлы, но загружает только те блоки, которых еще нет в репозитории, поэтому сбой стоит вам последних получаса передачи, а не последних трех дней. Успешное завершение работы с тем же архивом заменяет контрольную точку.

Restic загружает pack-файлы и индексные файлы по мере выполнения, поэтому повторный запуск пропускает данные, которые уже были доставлены. Если после сбоя остались pack-файлы, не упомянутые в индексе, команда restic repair index делает их снова видимыми, чтобы они использовались повторно, а не загружались второй раз. В версиях до 0.16 эта же команда называется restic rebuild-index.

При принудительном завершении клиента остается блокировка, и следующий запуск остановится с ошибкой Failed to create/acquire the lock. Убедитесь, что процесс действительно не запущен, затем удалите блокировку с помощью borg break-lock или restic unlock. Держите -o ServerAliveInterval=30 в BORG_RSH, чтобы неактивная TCP-сессия обнаруживалась через минуту, а не висела до тех пор, пока ядро не прекратит попытки соединения.

Хранение данных и предотвращение бесконечного роста репозитория

borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=12 --keep-yearly=2
borg compact

В Borg 1.2 эти две задачи разделены. prune удаляет записи архивов, а compact освобождает место на диске путем перезаписи сегментов. Если пропустить compact, размер репозитория не уменьшится, как бы часто вы ни выполняли очистку. Если в репозитории хранятся архивы из нескольких источников, добавьте опцию фильтрации архивов, поддерживаемую вашей версией Borg, поскольку prune без фильтра учитывает все доступные архивы. Аналог в restic выполняется одной командой: restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2 --prune.

После первого копирования каждый ночной запуск загружает только измененные блоки, поэтому рост зависит исключительно от типа хранимых данных. Библиотека документов и фотографий меняется на несколько гигабайт в месяц. Папка с образами виртуальных машин или полными дампами баз данных меняется почти полностью каждый день, и одна и та же политика хранения в этом случае потребует объема в несколько раз больше исходного. Запустите borg info через две недели и оцените необходимый размер VPS на основе этих данных, а не на догадках. Учитывайте стоимость терабайта в блочном хранилище по сравнению с объектным, когда размер репозитория превысит лимиты вашего тарифного плана. Также помните, что снимок (snapshot) VPS — это инструмент, отличный от резервного копирования: он защищает машину, на которой находится репозиторий, а не NAS.

Проверка резервной копии и восстановление из неё

Непроверенная резервная копия — это лишь предположение. Нижеприведенные проверки требуют разного объема сетевого трафика, поэтому они выполняются по разному расписанию.

• Еженедельно, на VPS: borg check --repository-only /srv/borg/nas1. Эта команда проверяет контрольные суммы сегментов и индекс репозитория без расшифровки данных, поэтому она не требует ключа и не потребляет трафик. Добавьте её в crontab пользователя root на VPS.
• Ежемесячно, с NAS: borg check --archives-only. Эта команда считывает метаданные архива. Поскольку они зашифрованы, потребуется ключ, а метаданные будут загружены по сети. Объем метаданных невелик по сравнению с самими данными.
• Редко: borg check --verify-data расшифровывает и хеширует каждый блок, что означает загрузку всего репозитория. На медленном канале это может занять несколько дней даже при высокой скорости соединения.

Restic работает аналогичным образом. restic check проверяет структуру, а restic check --read-data-subset=1/12 раз в месяц считывает одну двенадцатую часть данных. Таким образом, весь репозиторий проверяется в течение года без необходимости разовой загрузки огромного объема данных.

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

borg list
borg extract --dry-run --list ::nas1-2026-09-05 volume1/documents/2026
mkdir -p /tmp/restoretest
cd /tmp/restoretest
borg extract ::nas1-2026-09-05 volume1/documents/2026
diff -r /volume1/documents/2026 /tmp/restoretest/volume1/documents/2026

Пути внутри архива хранятся без ведущего слеша, а borg extract записывает их относительно текущего каталога, поэтому тренировка начинается с cd. Отсутствие вывода у diff -r в конце — это ожидаемый результат. Версия restic — restic snapshots, за которой следует restic restore latest --target /tmp/restoretest --include /volume1/documents/2026. Если ваша сборка Borg поддерживает FUSE, borg mount ::nas1-2026-09-05 /mnt/borg позволит смонтировать архив как файловую систему только для чтения — это самый быстрый способ извлечь один файл.

Выполняйте тренировочное восстановление с машины, отличной от NAS, так как в день аварии именно NAS может оказаться недоступен. Достаточно ноутбука с установленным Borg, экспортированным ключом и парольной фразой. Это предложение — ваш план аварийного восстановления, убедитесь, что он выполним.

Место этого решения в правиле 3-2-1

Правило 3-2-1 означает три копии данных на двух разных типах носителей, одна из которых хранится вне площадки. NAS в связке с репозиторием на VPS — это две копии в двух разных зданиях, а использование VPS в качестве удаленного хранилища покрывает задачи, которые решает этот уровень защиты. Если файл существует только на NAS (например, фотографии с телефона были импортированы и удалены с устройства), то у вас остается всего две копии. Повреждение или удаление данных, которое не было замечено до истечения срока хранения, приведет к потере обеих копий.

RAID не является одной из копий. Зеркальный массив защищает только от выхода из строя одного диска. Он никак не помогает при случайном удалении папки или пожаре.

Дешевым вариантом третьей копии является USB-диск дома, который периодически подключается для обновления и хранится в отключенном состоянии. Это также обеспечивает быстрое восстановление: загрузка нескольких терабайт с локального диска занимает полдня, тогда как скачивание того же объема с VPS ограничено скоростью вашего интернет-канала. Состояние удаленного хранилища также имеет значение, и мониторинг SMART-данных и ошибок, требующих оповещения — это то, что можно сделать, только имея доступ root к машине, где хранится ваша последняя копия.

FAQ

Сколько времени занимает первое резервное копирование NAS на VPS?

Разделите исходящую скорость соединения в мегабитах в секунду на 8, возьмите около 90 процентов от результата для учета накладных расходов, а затем разделите объем данных в мегабайтах на полученное число. Для 2 ТБ это составит 21 days непрерывной передачи на VDSL 50/10 и 5.1 days на VDSL 250/40. Любое ограничение пропускной способности прямо пропорционально увеличивает время, поэтому задача, ограниченная половиной скорости канала, выполняется в два раза дольше.

Можно ли запустить Borg или restic на Synology NAS?

На моделях с архитектурой x86 и установленным Container Manager можно запустить любой из них в контейнере, предоставив доступ к общим папкам. Модели на базе ARM часто не поддерживают этот функционал, а установка бинарных файлов вне системы пакетов обычно приводит к сбоям после следующего обновления DSM. Хорошо работают две альтернативы: настроить Hyper Backup на rsync-цель на VPS или запустить Borg на небольшом постоянно включенном Linux-компьютере, который монтирует общие ресурсы NAS, смирившись с более медленным сканированием и потерей метаданных о владельцах файлов.

Достаточно ли rsync на VPS для резервного копирования NAS?

Это дает вам удаленную копию, но не обеспечивает историю версий. Файл, удаленный или зашифрованный на NAS, будет удален или зашифрован на зеркале при следующем запуске, и вы узнаете об этом только через несколько недель. Используйте версионируемый репозиторий, то есть Borg, restic или собственную задачу версионирования от производителя, и ограничьте права SSH-ключа сервера режимом append-only, чтобы NAS не мог уничтожить уже сохраненные данные.

Что произойдет, если NAS и ключ шифрования будут утеряны?

При использовании keyfile шифрования репозиторий невозможно прочитать без экспортированного файла ключа и парольной фразы, поэтому храните этот экспорт там, где ни одна из машин не сможет его достать, например, в менеджере паролей или в виде распечатки из borg key export --paper. При использовании repokey зашифрованный ключ находится внутри репозитория, и для восстановления достаточно только парольной фразы. В любом случае протестируйте процесс восстановления до того, как он вам понадобится, восстановив один каталог на ноутбук, который никогда не подключался к репозиторию.