Сначала придётся поменять запятые внутри кавычек на что-нибудь другое, потом отсортировать, а потом заменить заменитель кавычек обратно на кавычки. Короче, sed с регэкспами поможет.
freeSTUD, А если у вас система на серваке, который раздаёт эту папку, приляжет? Будете руками заново поднимать и потом ещё несколько часов бэкап сетевой папки туда вливать?
Тогда как у Veeam есть механизм Instant recovery. С его помощью сервак можно в прод вернуть минуты за три.
Константин Лунтовский, то, что вы их исключили -- означает, что Veeam их бэкапить не будет. Но в настройках виртуалки-то они всё равно остаются, и когда вы её из бэкапа поднимаете, виртуалка пытается подцепиться к сетевым хранилищам. По какой-то причине ей это не удаётся.
Ну, если быть совсем точным, то iSCSI-target Veeam в любом случае бэкапить не будет на виртуалке -- у него таких механизмов нет, т. к. он пользуется API VMware.
В Veeam есть возможность задать pre-freeze/post-thaw скрипты. Выполняются перед созданием снапшота и по окончании его создания. Думаю, можно попробовать не отключать инициатор перед бэкапом, а просто отключать его автозапуск (в духе systemctl disable ...), а в post-thaw скрипте опять включать его автозапуск. Тогда восстановленная из бэкапа виртуалка при запуске не будет пытаться подключиться к iSCSI target. Когда загрузится, руками запустите.
Товарищ, а вы сами читали, что вам система пишет? :-) Непонятно, откуда вы взяли информацию про повреждение суперблоков. По крайней мере из тех скринов, что вы выложили, это никак не следует.
Во-вторых, я вижу, что система отмечает sda5 как clean, а это как раз рутовый раздел. Т. е. с локальной ФС всё в порядке, а вот фэйлится у вас монтирование раздела /backup_iscsi. Что нам как бы намекает, что перед снапшотом надо бы тормозить iSCSI инициатор на виртуалке.
GavriKos, контейнеры ничего общего с виртуализацией не имеют. Ну кроме того, что контейнеры можно внутри виртуалки крутить :-) Но не наоборот ;-) У контейнеров совсем другой принцип изоляции, основанный на линуксовых механизмах namespaces и control groups.
Денис Сечин, Что непонятного-то? Он прямым текстом пишет, что "нет А-записи для mx.wifi.gw". Вы назначили этот хостнейм в качестве MX-а для зоны, но при этом сам этот хостнейм никуда не резолвится, так как А-записи для него не прописано в вашей зоне.
Ну и отдельно вообще непонятно -- исходя из названия зоны в named.conf и файла зоны -- вы пытаетесь создать заглушку для ya.ru. Но при этом в конфиге определяется зона wifi.gw. Это зачем такая мешанина?
Артём Чеботарёв, всё знать невозможно, забудьте. Это я вам как админ-универсал говорю :-) Любая область, с которой мне приходится сталкиваться, скрывает под собой такие глубины, что никакого времени не хватит их осваивать. Поэтому в основном идёт тралирование по поверхности и чутка вглубь. Любой узкий спец заткнёт любого универсала в свой области за пояс очень даже легко. Другой вопрос, что сфер, где может потребоваться узкопрофильный админ -- не так много. Это, в основном, операторские сети (или приравненные к ним, типа сетей mail.ru или яндекса), или администрирование БД. Во всех остальных местах так или иначе нужна диверсификация знаний.
Главное правило для универсала -- влезать в технологию немножко глубже, чем того требует поставленная задача, но при этом без фанатизма.
Хотя, пока молодой, и семьи/детей нет -- тогда оно да, можно красноглазить ночами напролёт :-) Я, например, себе сейчас уже такого позволить не могу.
whatisit1, только опытным путём :-) Если виртуалки начнут много времени проводить в Co-Stop -- значит, нужно смотреть, у кого можно отжать процессоры. Заведите мониторинг и смотрите под нагрузкой на счётчики производительности, которые Варя отдаёт.
ky0, от этого процедура не меняется -- данные в БД синхронизируются репликацией, потом старый сервер стопится, новый делается мастером, переносится старый IP на новый сервак и запускается сам Zabbix-сервер с отреплицированной БД.
Dmitry Tallmange Ну технически там нужно делать не только DST, но и SRC NAT. Т. е. клиент 1.1.1.1 отправляет пакет на "прокси" 2.2.2.2, на определённый порт. "Прокси" делает SRC NAT от своего имени и отправляет пакет дальше, на сервер 3.3.3.3, на необходимый порт сервиса.
Другой вопрос, что это геморрой, который не стоит свеч. И больше принесёт проблем, нежели усилит защиту. Например, сервер 3.3.3.3 не сможет видеть реальных IP-адресов клиентов, что усложнит отладку и расследование инцидентов. Нужно будет костылить на ретрансляторе запись netflow, например, чтобы была информация, откуда и на какие сервисы ходили, и потом сопоставлять две базы -- логов сервиса и netflow.
В общем, гораздо правильнее обеспечить защиту сервисов на местах (т. е. на тех серверах, где они работают). Либо собрать всё на одной площадке, на серых адресах, и действительно поставить некий шлюз с белым IP между ними.
