Многоступенчатая организация хранения резервных копий для самых маленьких

[keenx]

Спасибо большое! Очень нужная статья. Такое решение давно зрело в уме, теперь можно перейти к действиям.

[paranoya_prod]

Как я понял, бекапы никак не проверяются на наличие ошибок?

[Dorlas]

Скрипт проверяет при синхронизации хеши файлов.
А вот то, что сделал бесплатный Veeam Backup — увы, не проверяется никак (автоматически).
Пока решили ручным способом 1 раз в квартал тестировать бекапы (восстанавливать виртуалки в отдельный vSwitch и тестировать.

[Dorlas]

А вообще, есть все необходимые инструменты для того, чтобы написать скрипт для автоматической проверки:
1) PowerShell модули в бесплатном Veeam чтобы восстановить виртуалки с новыми именами
2) PowerCLI к ESXi/vCenter, чтобы изменить им vSwitch и запустить их после восстановления
3) Организовать проверку запущенных виртуалок с помощью опроса IP-адресов, служб и т.д. (PowerShell скорее всего тоже — типа HTTP GET, ping и т.д.)

Возможно в будущем эта идея найдет практическую реализацию )

[kxl]

слабое место — подключаемый диск все равно виден целиком и, если зловред уже в системе, то он, как правило успевает зашифровать файлы, пусть не все сразу, но постепенно… ещё вопрос — получится ли отсоединить диск после бекапа, если на нем будут открыты файлы (антивирусом или зловредом)?

[kxl]

лучше всё-таки по сети передавать, на ftp например

[Dorlas]

Тогда уж лучше забирать с FTP (ставить на сервер с Veeam FTP-службу — например FileZilla FTP Server) и по расписанию с него забирать бекапы. Но да — идея хорошая.
Есть еще надежда на ZFS и его снапшоты (делаются каждый день, удаляются ротацией через 14 дней).
Если «зловред» будет шифровать махом и все разом — в снапшотах на ZFS будут оригинальные файлы.
В общем надежда на гибридный подход — что все «преграды» разом не обойдут (особенно автоматизированный скрипт — не человек).

[ChampionLoo]

Во всём есть слабое место, поэтому и сохраняют копии в трёх местах. Простите, конечно, но комментарий будто ради комментария писался.

[pnetmon]

А не проще заместо подключения диска использовать другой компьютер у которого отключается сетевой интерфейс?

[Dorlas]

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

[aik]

синхронизировал каталог A с сетевым ресурсом B, доступным через протокол SMB

Здесь иногда выплывает подводный камень с длинными русскими именами. За фрю не поручусь, а вот когда сервер на линуксе, то файлы с именами длиннее 127 символов не копируются без серьезных танцев с бубном (типа перехода нa reiserfs, к примеру).

[durnoy]

Да, это беда. В протоколе SMB ограничение на длину имени файла 255 символов, которые есть UTF-16 code units — опять же определено протоколом, а в Линуксе у обычных файловых систем — это 255 байт, которые обычно UTF-8.

[aik]

В протоколе SMB ограничение на длину имени файла 255 символов

Скорее в NTFS, чем в протоколе.

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

[kisskin]

а если на внешний диск/папку с бэкапами сделать доступ на запись только для пользователя, от которого пишутся бэкапы на него, это спасет от крипторов?

[Dorlas]

Спасет при условии, что скрипт(вирус) не проверяет и не пытается править права NTFS.

[Lelik13a]

Необходимо обрабатывать коды возврата вызываемых утилит.
А так же желательно слать отчёты о бекапах на почту, особенно, если что не так.
И полезно проверять размеры получившихся бекапов на адекватность.

[varnav]

Бекаплю целиком только два legacy сервера.

Остальное сделано иначе — бекапятся только данные (duply/duplicity на Amazon S3), развёртывание нового сервера с помощью скрипта (даже Ansible не нужен) делается быстрее чем восстановление его из бекапа.