Штатный 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 и файлы будут присутствовать на диске в единственной копии пока хотя бы один бакап на них ссылается (читай симуляция дедубликации)
Средний
Простой
Средний
