landergate

ISPConfig является NS-сервером для Вашего домена (this.dom)?
Ваши пользователи получают ответы DNS Вашего домена именно через ISPConfig? То есть он используется у ваших пользователей, как DNS-сервер?

Если нет, то добавьте A-запись "redmine.this.dom" на том DNS-сервере, который используется у пользователей.
Если да, то направьте "redmine.this.dom" на IP-адрес Redmine, доступный Вашим пользователям.

Затем настройте веб-сервер у Redmine (nginx?) таким образом, чтобы он принимал подключения по имени домена, вместо IP-адреса.

Upd:
kosatchev: Ага! Значит, ваши пользователи подключаются к вам через интернет, используя публичный DNS, и ваш ISPConfig не является для них NS-сервером.

Вам не нужно создавать A-записи на ISPConfig. Можете прибить "A my-redmine.com 192.168.0.22" и "redmine.this.dom 192.168.0.22".

Создайте у доменного регистратора в управлении вашим доменом A-запись redmine.this.dom, указав её на ваш роутер.
Если у вас нет ещё одного внешнего IP-адреса для Redmine, то вам на роутере понадобится nginx (или другой веб-маршрутизатор), который сможет показать пользователю разную страницу в зависимости от запроса - this.dom или redmine.this.dom.

Если возможности установить nginx на роутере нет, купите недорогую VPS у любого облачного провайдера за 3-5$ в месяц и настройте nginx на нём.

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

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

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

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

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

Как "кулхацкеры" заливают свои скрипты на сервер

1. Через загрузку файлов, если веб-приложение, при определённых обстоятельствах, способно исполнять эти файлы, как код. Можно изолировать upload-папку от какого-либо исполнения, или хранить тамошние файлы на отдельном сабдомене без всяких PHP.
   
2. Через SQL Injection, заставляя сайт исполнять произвольные команды, включая загрузку своих скриптов.
   

Теория и ряд практик по этим и другим угрозам в веб-приложениях структурированы здесь: https://www.owasp.org/

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

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

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

Как это реализовать?

Технология называется "Single Sign-On". Возможно для ваших CMS уже есть реализации, но если нет - можно написать её по существующим примерам.

Ещё подобное делают через "OAuth2", но для связи своего же сайта и его подсайта это будет избыточно. Обычно его строят для авторизации через совсем сторонние сервисы, над которыми управления нет. С другой стороны, возможно для вашего первого движка уже есть готовый плагин "OAuth2 Provider", а для магазина "OAuth2 Consumer".

Использовать одну базу данных или лучше разные?

Не имеет особого значения.

Если ваш интернет приходит в роутер, настройте на нём Port Forward нужного порта на локальный IP вашего компьютера и порт приложения. Раз это веб-сайт, скорее всего приложение использует 80 порт.

Если хочется, чтобы сайт извне был доступен по красивому имени, купите домен и направьте его A-записи domain.com и www.domain.com на ваш статический IP.

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

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

Хорошим вариантом будет Microsoft Azure.
Редкий провайдер, у которого вы не платите за простой ресурсов у выключенной машины.
К тому же, хостинг от того же вендора, что и ОС. =) В некоторых задачах у этого есть свои преимущества.

Подскажите, все ли правильно я вижу

Да, по-моему подход работающий.

Для того, чтобы не блокировать таблицу/не замедлять работу приложения инсертом с каждого посещения, некоторые приложения делают INSERT во временную MEMORY-таблицу (предполагается, что у них более быстрый INSERT), а оттуда раз в, например, 10 минут добавляют все накопившееся в основную таблицу. Правда MEMORY-таблицы не хранятся на диске, и если вы перезапустите службу в момент, когда какие-то просмотры будут в этой временной таблице, то эти незаписавшиеся в основную таблицу просмотры потеряются.

• Исторически, до появления VPS/VDS, как альтернатива shared hosting-у с полным контролем над сервером (root) и его настройкой.
  
• Для размещения высоконагруженных приложений/сайтов, если не хватает мощности shared hosting/VPS.
  
• Для размещения высоконагруженных приложений, связанных с вычислениями на CPU, когда нужно несколько ядер и т.д.
  
• Для размещения приложений с большим потреблением RAM, т.к. у виртуальных серверов RAM - самый дорогой ресурс.
  
• Для установки гипервизора и разбития сервера на много виртуальных мини-серверов для изоляции приложений друг от друга.
  
• Для установки гипервизора и перепродажи виртуалок (сам себе хостинг).
  
• Для хранения данных в конкретном ДЦ в конкретной предсказуемой стойке, вместо абстрактных ездящих облаков, за которыми нет контроля (если, например, по каким-то причинам нет доверия к облачному провайдеру).
  

Выбирая dedicated server, позаботьтесь об отказоустойчивости вашего сервиса на случай выхода из строя оборудования, чтобы сервис не оставался оффлайн, пока хостер ищет замену комплектующего.
От этого полностью не застрахованы и облачные провайдеры (ведь там такие же гипервизоры на неком оборудовании), но предполагается, что они делают live migration с проблемных нод.

Видел много топиков у dedicated-провайдеров в ключе "подлецы, ненавижу, когда поменяете мне комплектующее, у меня простаивает бизнес, я теряю 12000$ в час!".
Спрашивается, если сервис настолько прибыльный и потери столь неприемлемы, почему нельзя было инвестировать хотя бы в минимальную отказоустойчивость, вместо того, чтобы рассчитывать на мифическую вечную безотказную работу всего одной железки?...

1. Скрывать дублируемую новость с помощью JS, подгружая вместо неё ещё +1.
   
2. Подгружать новости не по offset, а по < ID загрузившихся новостей (из колонки ID).
   

я пользовался var_dump

Альтернативы:
- pprint
- repr
- print vars(someObj)
-

from inspect import getmembers
from pprint import pprint
pprint(getmembers(someObj))

Про отчёты сайта внутри Google Search Console:
Честно говоря, я не пробовал запрашивать удаление данных у поддержки. Вдруг, вам пойдут навстречу?

Но если попытаться обойтись своими силами, то:

• Ошибки сканирования (типа возвращённых 404, 503) можно убрать, нажав рядом со ссылками "отметить, как исправленное".
  
• Статистика сканирования ограничена 90 днями, и затрётся по прошествии сама.
  
• "Анализ поисковых запросов" тоже ограничен по времени и затрётся новыми.
  
• На "Ссылки на ваш сайт" повлиять нельзя, это фактические ссылки со сторонних ресурсов на ваш сайт. Тем не менее, поисковики учитывают трешевость сайтов, если вас беспокоят ссылки с левых накручивалок.
  

-----

Про отображение материалов сайта в поисковиках:
Из поисковиков невозможно заменить весь индекс сайта за короткое время. Это автономный процесс, на который принудительного влияния нет.

Применив рекомендуемые поисковиком практики (например, sitemaps), попытайтесь заставить его поисковых пауков как можно быстрее прийти на ваш сайт, где они обнаружат, что у него кардинально изменилась структура сайта, отсутствуют прежние страницы (например возвращают 404), изменено содержание страниц. Всё это стриггерит индексацию новых данных, и они постепенно появятся в поисковиках.

На моём опыте, поддержка поисковиков старается не вклиниваться в процесс влияния на ранжирование/отображение контента, объясняя это тем, что система сама отобразит изменения спустя какое-то время (1-2 недели, возможно месяц).

VeraCrypt умеет шифровать разделы диска (и не только), а также создавать скрытые разделы внутри зашифрованных разделов (в случае принуждения, вы покажете подставной).

Отмонтировать разделы можно из GUI или командной строкой:
veracrypt /dismount /force
https://veracrypt.codeplex.com/wikipage?title=Comm...
Можно создать такой ярлык или придумать, как выполнять эту команду от имени администратора по сети.

Предстоит разрешить три проблемы:

1. Найти для принуждающего объяснение, зачем вы используете зашифрованный раздел на сервере. Например, от утечки данных в случае физического проникновения.
   
2. Алгоритм монтирования скрытого раздела.
   По умолчанию, разделы монтируются вручную. Иными словами, ОС загружается, администратор подключается к серверу и вручную вводит сначала пароль к зашифрованному разделу, затем пароль к скрытому разделу, и только после этого пользователям станут доступны эти файлы. Авто-монтирование с паролем можно автоматизировать, но при изъятии сервера, ведь понимаете, авто-монтирование произойдёт и у принуждателей.
   
3. Корректное сохранение данных пользователей в случае такого аварийного отмонтирования. Хотя, при появлении принуждателей, возможно это и не так приоритетно.
   

Если я правильно понял, вы хотите назначить на свой маршрутизатор A-запись, чтобы myhost.ru резолвился в ваш маршрутизатор.

NS - это сервер DNS, который обслуживает запросы к DNS. Через него же, вы меняете значения DNS.
Если у домена уже определены стандартные NS и ваш регистратор уже предоставляет вам управление DNS у себя в панели управления, значит вам не нужно изменять NS.

Я правильно понимаю для того чтобы у меня домен ссылался на мой ip достаточно оставить дефолтные NS + добавить А запись с "myhost.ru." "myip-adress"?

Верно. Достаточно создать в существующей панели A-запись.

NS-сервера меняют в том случае, если хотят сменить поставщика, обслуживающего управление DNS-записями и запросы к ним от пользователей.

Например, если вас не устраивает то, как происходит управление DNS-записями или время применения правок DNS-записей, или производительность DNS-сервера (частые атаки), и вы хотите управлять своими DNS в Amazon Route53, то вам нужно будет сменить NS-сервера на те, что предоставит Amazon Route53.

По умолчанию порты в Ubuntu, как и почти в любом дистрибутиве, открыты.

Убедитесь, что на Вашем сервере больше ничто не занимает порт 8080.
sudo netstat -tulpn

Одно из софтовых решений, работающих на любом гипервизоре (включая VirtualBox и другие предложенные):
CPU Killer: www.cpukiller.com

Он создавался как раз для этих целей. =)