"хостеры с автоматическим подключением https вышли из чата..."
ну правильно, зачем писать хостеру, если можно писать на серч - это же вроде как площадка всех технических поддержек
а не проще было забекапить сервер другим способом ? мы на горячую как-то переносили 1.5Тб, с железа на Esxi - все прошло успешно
вообще по опыту рекомендую ISP бекапить целиком сервера - так надежнее, есть хорошие решения типа veeam, достаточно бесплатной версии и для переноса самое то
Либо более простой способ - бекапы делать без файлов, но с бд и настройками панелей
далее вы просто делаете rsync или снапшот lvm раздела с сайтами (надеюсь почта у вас отдельная роль)
Это хороший вариант, но требует определенного опыта и навыков - так просто исп бизнес не мигрировать с сервера на сервер, нужно будет тюнить конфиги и бд самого испа. Но да, вариант очень действенный.
да, проще всего это скормить бэкапы локально
Появились вечные
ispmanager 5 business (7 штук, разные сроки обновлений, самая свежая до 2019-10-25)
VMmanager 5 OVZ (2 штуки, свежая до 2019-04-13)
VMmanager 5 KVM (4 штуки, свежая до 2019-06-20)
цена договорная, в лс
Реагируйте на жалобы своервеменно, пока вы "отдыхаете в субботу", хостер работает, и если вам важны ваши проекты - мониторьте абузы и реагируйте
а так, если ркн забанил весь сайт - то меры корректные, если страницу - то нет, можно заблочить отдельную страницу, а не весь сайт.
Советы выше - топ :)
ТС, если я правильно понимаю, Вы подключили к серверу бэкап хранилище, подтянули бэкапы юзеров и решили из актуального бэкапа их всех развернуть? А таких пользователей, наверное, больше 100? К сожалению, исп бизнес крайне неохотно восстанавливает пользователей, эта проблема известна мне как минимум с 2015 года. В чём суть:
- Первые 50-100 аккаунтов при таком же количестве доменов восстанавливаются быстро в зависимости от объема данных
- Далее панель начинает тупить - если в системе дополнительно установлен CL, то к восстановлению добавляются обработчики команд selectorctl, cagefsctl и это замедляет процесс
- На 150+ аккаунтах процесс восстановления замедляется по экспоненте
Что делать?
1) Как минимум не писать в саппорт испа - не помогут. Процесс оптимизировать не могут, на форуме испа создан не один топик на эту тему
2) Перенести бэкапы с удаленного хранилища на локальное. Т.е. банально, перекинуть бэкапы с удаленного фтп на диск, подтянуть их в исп и начать восстановление. Ускоряется значительно, т.к. не надо тратить время на передачу бэкапа и его последующий merge
3) Есть ещё способы, конечно, но они подразумевают ряд манипуляций и постоянный контроль, и это выходит за рамки вопроса
Есть 47 вечных лицензий с датами обновления:
до конца 2016 - 1
до 2017 - 6
до 2018 - 19
до 2019 - 21
все по 15$
в лс
ТС, на любом линуксе без дополнительных телодвижений у вас будет больше 30 млн инод на 500 гб места. У time4vps искусственное ограничение из-за openvz.
так оно не искусственное, а легко изменяемое в конфиге ct. Просто, скорее всего, стоит либо по умолчанию, либо % от quota
уменьшение inode_ratio при создании фс приведет к росту числа inode в ущерб свободному пространству диска :) это всё можно провернуть ручками без хостера, главное - прямой доступ к переустановке сервера/фс/rescue, кому как удобно
емнип, по умолчанию при создании фс идёт 16кб ratio, ставите 256б и живёте счастливо
либо используйте xfs, а не ext3/4 (на ext4 минимальный inode ratio = 1kb, для xfs = 256b)
