наведете на решение?
не смогу, потому что не знаю, готовых систем из коробки чтобы и бакапы делали, и дедупликация адекватная была, и контроль над результатом тоже был бы.
лирикавозможности и выбираемый инструмент полностью зависят от того как именно у тебя построены рабочие машины, какая операционная система, где и как хранишь файлы.
К примеру системный раздел windows можно адекватно бакапить только средствами копирования разделов (так как для их работу необходимо корректно восстанавливать не только acl но и hard- и symbolic- links (подскажите мне если знаете такой что сможет работать с бакапом на уровне файлов, кроме штатного от майкрософта но управляемость бакапами там нулевая, плюс почти никакой дедупликации, ну их нафиг)
И главное, никакая из известных мне систем резервного копирования не проводит полностью контроль над бакапами в том виде который требует идеология, а именно - возможность восстановить рабочую систему из бакапа. Максимум что могут сделать - проверить контрольную сумму результата (что само собой не спасет от ошибок в конфиг файлах). И это логично, так как собственно сам факт проверки работоспособности автоматизировать универсально невозможно.
Но вот в частных случаях, когда интегратору/админу известна система от и до, возможно построение своих скриптов автоматизации и формировании отчетов о тестировании среды.
По делу, одно время я пользовался в windows bat скриптами (готовые были написаны для
win7 и уже не работают в win10, но идея там простая, все переписывается легко) когда на целевом диске создавался снапшот, затем с помощью rsync создавалась полная копия указанных каталогов, но с указанием предыдущей версии реплики, для неизменившихся файлов утилита создавала hardlink на прошлую копию, в результате получается идеальная инкрементальная копия, с которой можно работать как с обычными файлами (не требуется извлечение из сжатых архивов и последовательное принятие патчей инкрементации), причем на любую сохраненную дату, при необходимости можно легко удалить старую или даже любую реплику, благодаря корректной обработки hardlink файловой системой.
Сам диск можно подключать по сети, на выбор либо средствами windows (.vhd файлы) либо iscsi
Сжатие - поддерживается, но только слабое ntfs.
Недостаток подхода, в момент создания резервной копии, требуется полный доступ на запись на весь архив, т.е. это жуть какая опасная операция, если что то случится не то, можно потерять все копии. Если закрыть глаза на руткиты, ломающие файловые системы минуя ОС, напрямую записывающие диски (маловероятный сценарий, от которого защищаться нужно еще до размышлений о резервных копиях), то защититься можно выставляя права доступа на старые реплики, на все есть консольные утилиты
Второй недостаток - год ежедневных копий с даже средним количеством файлов в итоговом разделе создаст миллиарды hardlink (лимит на количество hardlink на один файл - 1024, это примерно три года ежедневных бакапов), ну и к примеру, проверка такого диска с помощью chkdsk может потребовать дни и недели.
----------------------------------------
Другой подход, если требуется создание копий общей шары на сервере (linux само собой), выбираешь cow файловые системы, с поддержкой онлайн снапшотов - btrfs/zfs. Каждый день или даже каждый час создаешь снапшот и хранишь так долго как это необходимо, удаляя не нужные тогда когда пожелаешь (операция моментальная, не зависит от объема данных). Это защитит данные от проблем на клиентской стороне, например ошибочные удаления или вирусы-шифровальщики и т.п.
Чтобы защитить данные от проблем с серверным железом, то к примеру можно использовать фишку
btrfs incremental backup, когда разницу между двумя указанными снапшотами (предыдущим и текущим) отсылают на удаленный сервер, упаковав его в один файл (точнее поток). т.е. эти патчи можно хранить и применять на заранее сохраненное стартовое состояние файловой системы. Само собой удаленный сервер так же должен хранить снапшоты (кстати а патчи можно хранить на третьем сервере).
Т.е. в результате те же самые бонусы что и в первом подходе, но требует полноценный бакап удаленный сервер, принимающий и разворачивающий патчи снапшотов.
Сжатие так же поддерживается, причем можно использовать лучшую - zstd
В обоих случаях советую создание автоматических отчетов по изменениям (не только общие но к примеру по пользователям, сколько изменений какие пользователи сделали, в графиках), т.е. даже информация о размере снапшота более чем полезна, если нормально у вас еженедельно получать дифы размером X гигабайт, а сегодня внезапно получаете 0 или 100X это уже повод забеспокоиться.
----------------------------------------
Проверка бакапов на восстанавливаемость.
В сети должна быть машина, которая занимается только этим - по очереди поднимает бакапы каждой машины по отдельности или сразу целой инфраструктуры на виртуалках, стартует службы и базы данных и проводит какие то проверки. К сожалению создание адекватных автоматизированных тестов всей инфраструктуры задача слишком сложная и мало кто этим заморачивается, мало того, автоматически развернуть работающую систему из бакапов и запустить ее в работу - уже подвиг, поэтому придется этим кому то заниматься в полуручном режиме (т.е. сервис обеспечивает восстановление файлов, а человеку необходимо запустить и посмотреть на то, работает ли в принципе все как ожидается)