rPman

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

Самый известный протокол iscsi (лично я считаю его в большинстве ситуаций, особенно маленьких организаций и дома - перегруженным, но спасибо есть простые сервера для самодельных nas типа linux istgt).
До него был еще проще (с точки зрения нагрузки на сервер/nas) NBD (network block device) - очень простой и эффективный по ресурсам для NAS (особенно для слабых машин).
Есть еще старый AOE (ata over ethernet), он позволяет публиковать диск/образы по ethernet вне ip/tcp стека (т.е. минус оверхед от организации сети).
Еще нагуглил NVMe over tcp (я знал что есть по fibre такая технология, но что ее сделали по tcp я не знал).
Все это прекрасно работает в linux, но нужно смотреть поддержку NAS.

p.s. помимо организации самой работы, нужно думать что произойдет во время сбоя связи между сервером и NAS, к примеру если диски примонтированы mount (особенно если диски примонтированы на хост машине а не каждый диск внутри VM) то разрыв связи создаст проблемы на сервере, подвисание с длительным периодом решения этой проблемы.

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

По поводу организации резервного копирования, есть неплохие идеи при использовании мощных ZFS/btrfs файловых систем, у них встроенная и бесплатная по ресурсам система организации снапшотов, а главное есть возможность отправлять по сети/или хранить разницу между указанными снапшотами в виде файла (полный аналог diff/patch для текстов), и удаленно применяя эти патчи к холодной резервной копии (или просто хранить в виде файлов, но при необходимости их придется применять к стартовому состоянию на бакап сервере в правильном порядке без пропусков), на текущий момент это наилучший способ организации инкрементального резервного хранилища, универсально подходит под любые нужды, хоть VM хоть типовой сервер.

Встроенная в windows старая версия "резервное копирование и восстановление (windows 7)" умеет делать образ восстановления системы, позволяющий восстановить при полной потере системного диска. Целью размещения бакапа можно указать диск, компакт диск или сетевой диск.

Для создания в своих скриптах нужно использовать команду wbadmin. Команду можно разместить в штатном планировщике задач.

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

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

при любой ошибке Win

не решив эту проблему, вы не обеспечите себе надежную сохранность данных.

Аппаратный RAID - это попытка вынести критичную часть отдельно (идеальный вариант - NAS) что бы он выполнял только одну эту функцию но делал это надежно и хорошо. Проблема в том, что надежные аппаратные рейды по стоимости начинаются где то 5-значные суммы в рублях, дешевые платы - часто это некое подобие софтварного рейда и по факту являются просто платой подключения дисков (некоторые прямо так их и используют, настраивая стандартный софтварный raid операционной системы вместо того же софтварного рейда от производителя с вендорлок).

Теперь по теме. Если задача - повысить шансы сохранности данных при смерти жесткого диска (это единственная задача, которую решает raid), и вас устраивает неэффективное но простое зеркалирование, то используйте любые штатные инструменты операционной системы для синхронизации каталогов, начиная с простейшего copy и кончая фич cow файловых систем btrfs/zfs в linux, которые позволяют бесплатно и моментально получить слепок изменений между двумя снапшотами (которые тоже моментальны), сохранить его, скопировать куда-нибудь и применить этот патч (полная аналогия diff и patch, если вам так будет понятнее) на сторонней копии (не важно где она находится, не важно когда вы это сделали, т.е. можно хранить некое стартовое состояние и любое количество слепков изменений/патчей, которые по мере необходимости можно 'накатывать' на копию).

Почему zfs/btrfs удобнее высокоуровневых утилит типа rsync/cp, потому что для создания слепка не требуется время (максимум время на чтение нужного объема данных, причем очень эффективно для железа, почти линейно) и не зависит от количества файлов и сложности изменений (например если вы изменили 1 байт в середине гигабайтового файла, rsync будет копировать или сканировать весь файл, когда как btrfs snapshot прочитает только этот измененный кластер, то же самое при записи этих изменений - будет записан на диск только этот кластер).

Для windows я такого функционала не нашел. Есть какие то способы чтения ntfs mfat таблицы, от тела можно вытащить быстро списки изменившихся файлов.

Так же есть способы сбора изменений в файлах в процессе их изменения (аналог inotify) в Linux, эти пользуются всякие yandex/goggle/microsoft drive, точно помню открытый syncthing это умеет (кстати неплохой вариант для локальной синхронизации, не штатный его режим но вроде можно выкрутиться)

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

rsync

Умеет все что вы запросили, бакап - пофайловая копия (т.е. бакапы доступны как файлы без дополнительных телодвижений), умеет инкрементальное копирование через создание симлинков
Можно копировать как сразу по сети с удаленной машины так и запускать по ssh (сервер штатно ставится в windows), инициируя бакап с центральной машины.

Для резервного копирования загрузочного диска (что бы можно было без проблем его восстановить) - liveusb/netboot linux + partclone (быстрее dd даже с тормозными hdd), если нужно рулить этим вручную, то на их основе есть готовый clonezilla

p.s. еще есть syncthing, прекрасная утилита с web gui, умеет синхронизировать указанные каталоги с указанными машинами где угодно, с поддержкой инкрементального бакапа (ограниченно). Многим этот функционал кажется удобнее и народ тупо отказывается от всяких гуглдиск/onedrive/...

странно, в документации к rsync написно что delta-algorithm работает по умолчанию, можно задать размер блока

--block-size=SIZE, -B
This forces the block size used in rsync's delta-transfer algorithm to a fixed value. It is normally selected based on the size of each file being updated. See the technical report for details.

Beginning in 3.2.3 the SIZE can be specified with a suffix as detailed in the --max-size option. Older versions only accepted a byte count.

включить/выключить опциями:

--whole-file, -W
This option disables rsync's delta-transfer algorithm, which causes all transferred files to be sent whole. The transfer may be faster if this option is used when the bandwidth between the source and destination machines is higher than the bandwidth to disk (especially when the "disk" is actually a networked filesystem). This is the default when both the source and destination are specified as local paths, but only if no batch-writing option is in effect.

--no-whole-file, --no-W
Disable whole-file updating when it is enabled by default for a local transfer. This usually slows rsync down, but it can be useful if you are trying to minimize the writes to the destination file (if combined with --inplace) or for testing the checksum-based update algorithm.

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-ов можно очень долго из них восстанавливать последнее состояние