rPman

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

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

Штатный ntbackup в режиме fast (инкрементальный). Лично мне не нравится, неудобно, но зато штатно и все мышевозекательно.
---
Любой архиватор, позволяющий добавлять в архив либо по флагу archived либо по дате, простенький скрипт из трех строчек, сохраняешь дату бакапа в имени файла бакапа и следующий бакап делаешь на основе этой даты с предыдущего (у меня было два каталога - один для последнего единственного файла и второй для всех остальных - при запуске бакапа я брал имя этого единственного файла, делал бакап в этот же каталог и после его успешного завершения перемещал файл старый во вторую папку... если в каталоге два файла при запуске - значит предыдущий бакап корректно не завершился, и значит более новый файл удалить и повторить попытку.

Делать бакапы - пол дела, их нужно проверять. В случае с инкрементальными бакапами нужно держать где то распакованную версию с последней проверки и помнить дату этого бакапа, разворачивая в нее все последующие инкрементальные архивы. Я тогда не заморачивался с удалением файлов (в планах было хранить список файлов в момент бакапа и сравнивать их скриптом но особой необходимости в этом не было а потом перешел на rsync). Недостаток инкрементальных бакапов, если потерять этот развернутый тест-бакап, то что бы восстановить состояние каталога на последнее - нужно будет последовательно развернуть все, начиная с самого первого стартового. Что бы этого не происходило, нужно периодически пересоздавать 'первый стартовый архив' из тестового, и удалять все бакапы старее.
---
rsync (есть продвинутая с патчами если нужно хранить права но по уму лучше брать ту что на основе mingw) - решил все проблемы, включая удобство использования (смотреть инкрементальную копию как обычный каталог тупо в far/проводник), добавив долгую проверку диска chkdsk после сбоя потому что там миллионы файлов. Это магический ключ --link-dest с его помощью можно указать каталог последнего бакапа, что то типа такого:

rsync -av --link-dest=/backup/%PREV% /mnt/d/ /backup/%CURRENT%

Тут PREV хранит дату (например dd-m-yyyy) предыдущего бакапа а CURRENT - текущего.

И самое главное, на NAS храни не сами файлы (так как по сети не будут переданы ни права доступа ни расширенные атрибуты ни симлинки... а .vhd образ (его можно тут же монтировать с помощью штатного diskpart). На диске сделай обычный ntfs, можно даже сжатие включить (или шифрование, как хочешь). Копировать так данные можно клиентами windows начиная с 7-ки (не starter и не home ревизии), т.е. скрипт резервного копирования запускать прямо на клиенте, который монтирует диск, делает резервную копию, и размонтирует... делать это рекомендуется по ssh с основного сервера, что бы гарантировать что один и тот же .vhd не будет смонтирован дважды (да там и не получится), но если так будешь делать, это значит клиенты будут иметь доступ (да можно права настроить но все же) ко всем бакапам,.. если nas поддерживает, на момент бакапа делать снапшот хранилища, и если бакап завершится без ошибок, удалять иначе откатывать назад и повторять.

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

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

Криптовалюта siacoin, оплата в криптовалюте, хранение дешевле amazon glacier (большая часть цены - трафик download уже сохраненного себе назад)
https://siascan.com/

Average storage price	Average download price	Average upload price
$1.33/TB	$3.72/TB	$0.11/TB

Цены приблизительные в месяц.

С точки зрения работы это фактически торренты (по умолчанию 3х резервирование и разделение на 40 мест хранения), все участники финансово заинтересованы продолжать хранить и раздавать данные, все зашифровано, децентрализовано.

Интерфейс на уровне типовых пользовательских приложений dropbox/onedrive (по умолчанию без веб интерфейса), есть api провайдеры (все локально без единой точки отказа) совместимого s3, есть драйвер файловой системы linux fuse и куча всего, дольше изучать...

p.s. с точки зрения майнеров проект не привлекательный, из-за странного поведения разработчиков, но так как у него есть использование, цены на эту криптовалюту не манипулятивные трейдерами. Проект живет почти 9 лет уже, так что имеет смысл для рассмотрения.

У qnap/snapshots есть свои же механизмы резервного копирования, зачем колхозить сверху что то ещё?:

ACL - во всех современных linux дает дополнительный слой прав поверх привычных chown/chmod.

Можно с помощью setfacl выдать дополнительные права на файловую систему специально созданному пользователю backup и тогда rsync с удаленной машины сможет залогиниться под этим пользователем и скопировать файлы.
Типа так:
sudo setfacl -R -m u:backup:rx /
а копирование с удаленной машины типа так:

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} backup@remote:/ /path/to/destination

дополнительно нужно будет настроить без парольную аутентификацию под пользователем backup на эту машину

p.s. резервное копирование больших объемов данных, особенно если файлы большие или, к примеру, во время резервного копирования могут быть записаны, потребует заморозку файловой системы с помощью снапшотов, выбор технологии которых накладывает различные ограничения, например LVS кратно роняет скорость работы файловой системы, на которой создан снапшот. Я бы рекомендовал cow файловые системы btrfs/zfs, у них из коробки максимально эффективная система снапшотов (на основе которой можно создать инкрементальные бакапы на порядок удобнее и быстрее чем с помощью rsync) но они роняют (десятки процентов на hdd) скорость работы баз данных в принципе... в общем нужно думать и правильное решение - исключить файлы баз данных из резервного копирования и настройка этого копирования уже средствами базы данных.

В общем полностью абстрагироваться от клиентских машин не получится, что то на них настраивать придется

Мне кажется вы перечислили самые дешёвые варианты, amazon s3 glacier deep будет тоже уровня цены.

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

Не представляю что то дешевле чем хранить данные там (порядка 2..5$/м за терабайт +-)... Когда-то по тестам скорость там получалась сотни мегабит, но логично лучше тестировать в своей локации, это ведь как торренты.

https://siascan.com/ смотреть на цену тут с осторожностью, так как могут не учесть x3 резервирование по умолчанию, лучше поставить клиент и смотреть цены там.

надежно это в каком смысле?

защититься от аппаратных сбоев - raid или кластерные файловые системы (аналог рейда по сети)

Защититься от ошибок в программе и кривых рук админа, тут сложнее, и только постоянные бакапы.

Вне зависимости от используемого клиента, если речь идет о mysql или postgres, можно настроить master-slave репликацию на другой сервер (в т.ч. в другой сети), и дополнительно делать резервное копирование базы средствами БД (чтобы не нагружать рабочий сервер, это можно делать на резервном). Это защитит базу от локальных катаклизмов (например пожар или кража оборудования) и отчасти аппаратных (поломка диска или сервера).

Чтобы надежно, в момент запуска бакапа, нужно останавливать работу с базой (останавливать сервер 1c), запускать бакап файлов исключая БД (например инкрементальный rsync или к примеру на основе снапшотов файловой системы btrfs) и тут же делать бакап базы данных.

Локальные (в течении дня) бакапы можно делать снапшотами файловой системы или системы виртуализации, внутри которой запущен сервер, это не защитит от проблем с оборудованием но даст возможность откатить изменения на момент бакапа. Если хотите делать такие бакапы при запущенном 1c сервере, то размещать это нужно в пределах одной виртуальной машины (база данных рядом) только тогда эта операция будет атамарной.
Снапшоты обычно бесплатная операция и они инкрементальны (не используйте снапшоты LVM они тормозят систему) а значит их можно делать часто.

Я помню для машин на windows7 использовал bat-скрипт (он уже не подойдет для win10) который делал примерно то же самое, создавал теневую копию копируемого диска, запускал rsync, который для дубликатов на основе предыдущего копирования создавал символические ссылки.

rsync -avh --link-dest=previous_backup/ source_directory/ new_backup_directory/

source_directory/ - это каталог, который нужно скопировать.
new_backup_directory/ - это каталог, в который будет создана новая резервная копия.
previous_backup - это предыдущий каталог резервного копирования. rsync будет создавать символические ссылки на файлы в этом каталоге, если они не изменились.

rsync можно брать как нативный виндовый так и использьзовать linux через wsl, рекомендую нативный (который на основе mingw)

По поводу работы с этим по сети, лично я делал не стандартно, диск, на который происходило копирование подключался по сети как блочное устройство (.vhd/.vhdx), сам же файл по сети раздавался сервером.

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

Копируя файлы с нескольких машины по очереди на один и тот же диск у меня появлялась возможность отдельным приложением сканировать диск на одинаковые файлы и делать их так же символическими ссылками (т.е. в пределах резервных копий с одной машины ссылки создавались с помощью rsync, но между машинами нет).

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

p.s. что значит интерфейс управления резервным копированием?

tar + встроенное в базу данных средства резервного копирования (так как копирование файлов базы данных не гарантирует ее корректное восстановление)
закачивать файлы на ftp можно хоть curl хоть консольным ftp да хоть скриптом на 5 строчек

p.s. если конвертировать файловую систему vps (это возможно для виртуалок типа kvm) в btrfs то можно воспользоваться штатным инструментом инкрементального копирования на основе снапшотов (он быстрее на пару порядков, так как копируются буквально только изменения средствами файловой системы ОС а не косвенно через полный рескан, как это делают rsync)

очень большие базы данных можно копировать, настроив master->slave репликацию (реплика и будет эта копия), при необходимости реплику можно приостанавливать, делать ее копию (тем же snapshot backup) и возобновлять работу.. в итоге интервалы между бакапами могут стать абсурдно маленькими (например минуты), Осторожно с инкрементальными бакапами, не копи их большое количество, лимитируй разумным интервалом и веди стартовое состояние на сервере хранения резервных копий, иначе к примеру храня миллион инкрементальных diff-ов можно очень долго из них восстанавливать последнее состояние

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

Добавь сохранение логов ( 2>>errors.log >>info.log ) к вызовам tar и rsync

Но есть совет!
Так как ты передаешь один единственный файл - .tar архив, нет смысла использовать rsync, достаточно scp, мало того, нет смысла даже сохранять промежуточно архив у себя. Достаточно передавать архив по ssh сразу в момент его создания, а успешность доставки проверять по коду ошибки, примерно так

tar -cvf - $BACKUPDIR |  ssh -p 55422 -i /home/pisarev/.ssh/id_rsa rsync@192.168.1.1 "cat /dev/stdin > /volume1/NetBackup/site/backup_$date.tar"

У вас должны быть какие то механизмы развертывания сайта на проде, не важно какие, хоть скрипты, хоть ansible, главное не вручную! Причем такие скрипты должны различать установку с нуля и обновление (обновление - отдельный разговор, к сожалению красиво и универсально с базами данных не получится, но стараться нужно, чтобы иметь повторяемость и тестируемость и получать хоть какие то гарантии того что процесс обновления ничего не сломает)

Мне нравится способ создания тестового окружения через снапшоты и репликацию...
Файлы могут попадать простым копирование (развертывание архива, rsync, набор патчей и т.п.) а база данных через поддержание онлайн реплики master->slave, на машине, где можно временно остановить slave реплику, снять снапшот с файловой системы или всей машины (например виртуализация), и поднять копию параллельно в другой сети (виртуальные машины очень красиво позволяют все это разрулить с автоматизацией).

Этот подход позволяет поднять тестовое окружение с текущей базой данных за минуты, вне зависимости от ее размера (хоть терабайты), время развертывания скорее зависит от того как долго будет останавливаться реплика (ожидание завершения текущих операций записи)

p.s. во время развертывания обновления, обычно сильно затрагивающего базы данных, советую держать 'рядом' предыдущую версию с возможностью оперативно откатиться, нервов и времени сбережете очень много