landergate

Пакеты, установленные внутри virtualenv, доступны только при активации virtualenv. За пределами их, по умолчанию, нет. Запуск интерпретатора вне virtualenv обращается за пакетами в глобальные системные директории, а не в virtualenv.

gunicorn нужно установить через pip внутри virtualenv и вызывать его из virtualenv/bin/
docs.gunicorn.org/en/stable/deploy.html#using-virt...

По какой-то причине, DNS-запись "spb.dormall.ru" резолвится не у всех пользователей.
У меня, например, он не открывается, как и с ряда других серверов из разных точек РФ и мира - где-то резолвится, где-то - нет.

В NS-серверах домена числится два DNS-провайдера: Fast DNS и Yandex.
dns.fastdns24.com
dns1.yandex.net
dns2.fastdns24.org
dns2.yandex.net
dns3.fastdns24.eu
dns4.fastdns24.link

Вы уверены, что А-запись spb.dormall.ru присутствует и там, и там?
Если вы сопровождаете DNS-записи только в одном месте, не используя второе, то его нужно убрать из списка NS-серверов домена.

Да, редирект работает правильно.
Он отдаёт паукам Google ответ 301 с нужной ссылкой.

Теперь весь индекс, связанный со старой ссылкой, будет перестраиваться на новый адрес.

1. Обеспечьте общую внутреннюю сеть между 1 и 2 сервером.
   
2. Поставьте nginx на 1 сервер, указав в качестве бэкенда ваше веб-приложение на 127.0.0.1.
   
3. Разверните копию nginx, файлов сайта и структуру БД на втором сервере.
   
4. Убедитесь, что с первого сервера есть связь к вашему веб-приложению (ему самому, а не nginx) через внутреннюю сеть.
   
5. Однажды ночью, проведите короткую профилактику, остановив первый сайт.
   
6. Перенесите данные БД с первого сервера на второй.
   
7. Настройте на первом сервере у nginx в качестве бэкенда второй сервер.
   
8. Смените DNS с первого сервера на второй.
   

Теперь ваше веб-приложение работает на втором сервере, а при подключении к первому, пользователь получит результат работы второго сервера.

Первый сервер можно оставить в эфире до тех пор, пока к нему не прекратятся соединения.

--
P.S. Чтобы не морочиться с внутренними сетями (хотя это несложно сегодняшними средствами), вот альтернатива первому пункту:
Откройте в фаерволе на втором сервере возможность первому серверу подключиться прямиком к веб-приложению по его порту. В 7 пункте, nginx можно будет настроить на публичный адрес и порт приложения. Учтите, что трафик между двумя серверами в этом случае шифроваться не будет. Рисков в связи с этим не очень много, но, при желании, соседи или ЦОД смогут "подслушивать" ваш трафик между серверами.

База данных препятствует добавлению новых данных на период снятия бекапа для того, чтобы Ваш бекап был консистентен по всем таблицам. Это стандартное поведение.

Консистентность важна для того, чтобы не получилось так, что Вы начали бекапить, забекапили первую таблицу, переходите ко второй, а в это время в первую таблицу сайт что-то записал, добавив связанную запись в третью таблицу. В бекапе останутся актуальные данные для второй, третьей, но не первой таблицы.

Если Вы хотите делать бекап без блокировки таблиц, но Вам важна консистентность данных, Вы можете:

1. Настроить репликацию MASTER-SLAVE и снимать резервные копии со SLAVE. С ним можно будет сколько угодно блокировать таблицы бекапами, поскольку SLAVE-сервер не будет использоваться сайтом. Все новые данные с MASTER доедут на него после завершения бекапа.
   
2. Если таблицы в InnoDB, то можно освоить XtraBackup, делающий резервную копию прямо на ходу.
   

Если Вы хотите делать бекап без блокировки таблиц, но Вам не нужна консистентность данных:
Для MyISAM:
mysqldump --lock-tables=false ...
Для InnoDB:
mysqldump --single-transaction ...