Действительно ли возможно определить блок в зональном файле как постоянный в Динамическом DNS (использование связывают)?
Вы выполняете команду mysqldump на сессии SSH. Это немного похоже на былые времена DOS, Вы могли бы сказать в том, что вводите в ряду команд для получения сделанной работы. Это не имеет никакого отношения к PHP или MySQL.
Где Ваш веб-сайт размещается? Они обеспечивают доступ SSH?
Если они делают и Вы разрабатываете под окнами, можно использовать программу под названием Шпаклевка для "выполнения SSH к веб-серверу". Таким образом, если доступ SSH к Вашему веб-серверу доступен.
В противном случае, возможно, они обеспечивают альтернативный способ получить резервное копирование? как через phpmyadmin?
Да, вы можете иметь два файла для одной зоны. Вдобавок предлагаю делать все динамические обновления в субдомене. Комбинируя оба из них, вы можете изолировать все машинные правки.
Добавьте это в конец файла зоны:
$INCLUDE dynamic-zone-file.conf dyn.example.com
Все динамические обновления будут затем идти в dynamic-zone-file.conf . Этот файл должен существовать и быть доступным для записи пользователю с именем .
У меня мы храним динамические обновления, содержащиеся в их собственных зонах. Я не могу придумать, как поддерживать порядок в файле зоны, если он получает динамические обновления. Я не уверен, что вы пытаетесь сказать «возможно ли вернуться к исходному файлу зоны». Вы говорите, что вам не нужно, чтобы динамические обновления были постоянными между перезапусками BIND? Если это так, просто напишите сценарий, который копирует файл основной зоны, который вы храните и редактируете где-нибудь до запуска BIND.
Определите «калечить». Если вы имеете в виду «перезаписать», тогда да, BIND должен перезаписывать файл зоны каждый раз, когда вы делаете обновление. Моя политика всегда заключалась в том, что после того, как файл зоны был открыт для динамических обновлений, он никогда больше не изменялся вручную, и вам приходилось использовать механизм автоматического обновления, чтобы что-то делать (много вызовов nsupdate или просто использовать API веб-интерфейса, который мы настраиваем).
Чтобы ответить на другие ваши вопросы:
«возможно ли иметь 2 или более файлов зоны, описывающих один домен?» - правильным термином для «домена» в BIND является «зона», поэтому, если мы перепишем ваш вопрос так, чтобы он был «возможно ли иметь 2 или более файла зоны, описывающие одну зону?», ответ станет довольно очевидным. Имейте две отдельные зоны, как описано в mghocke, если вам нужно что-то подобное.
"Можно ли возвращаться к исходному файлу зоны при каждом запуске DNS?" - Конечно, просто пусть ваш сценарий запуска DNS скопирует файл базовой зоны на место. Нет лучшего способа сделать это, потому что это не то, что кто-то когда-либо хотел бы делать - принимать динамические обновления, а затем выбрасывать их каждый раз, когда вы перезапускаете DNS-сервер. Одно предостережение при использовании этого метода заключается в том, что вам нужно будет обновить серийный номер при копировании файла базовой зоны, иначе ваши подчиненные не будут выполнять передачу зоны.
Мои экстрасенсорные способности подсказывают, что вы пытаетесь смешивать вручную (прямое) редактирование файла зоны с динамическими обновлениями. Просто чтобы вы знали, это не сработает (в наивном случае) - рано или поздно вы вступите в гонку между динамическим обновлением и ручным редактированием файла, и динамическое обновление победит, что приведет к потере вашего ручного обновления. Вам нужно будет замораживать и размораживать зону каждый раз, когда вы хотите отредактировать (удачи, когда вы используете , что ). Это причина моей политики «все изменения в динамических зонах должны выполняться через интерфейс DDNS».