df-n

Посмотрите внимательно ваш конфиг.

findtime  = 3
maxretry = 2

т.е. время поиска в логе - 3 секунды, за это время в логах должно быть 2 повторения, тогда сработает. Увеличьте findtime в требуемых секциях, имхо, 3 секунды - очень мало.

И еще, при настройке f2b рекомендуется jail.conf не трогать, а свои собственные настройки, отличающиеся от дефолтных, помещать в ф-л jail.local, иначе после обновления f2b неожиданно все может перестать работать.

Нужна дополнительная информация чтобы разобраться.

Как именно вас банит ?- это касается только доступа по ssh или после бана сервер полностью становится недоступен ( не отвечает на ping, нет доступа к www и т.д.)? Т.е. блокируется только 22 порт или вообще все ?

Если есть возможность во время бана подключиться альтернативным способом, то можно вначале поставить screen, запустить в нем, например,

tcpdump -n -i eth0 src or dst (ваш ip)

Получите в выводе перехват пакетов между вами и сервером. Затем воспроизвести бан. После забанивания - запускаете, например ping на сервер или пытаетесь зайти по ssh, подключаетесь альтернативно, цепляетесь к screen и смотрите вывод tcpdump. Если пакеты есть - надо искать причину на сервере. Если пакетов нет - искать снаружи.

Если нет возможности зайти во время бана альтернативно, то запускаете

tcpdump -n -i eth0 -w tcpdump.dump src or dst (ваш ip)

После разбанивания - цепляетесь к screen и считываете из файла

tcpdump -n -i eth0 -r tcpdump.dump src or dst (ваш ip)

можно с дополнительными опциями.

И еще любопытно, что это за процесс

Интересная проблемка.

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

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

Если это проблема на сервере - внимательно смотрим на запущенные процессы т.д.

GPT имеет две дублирующие информацию таблицы разделов, в начале и в конце диска. Судя по выводу, на старом диске эти таблицы не совпадают. Следовательно это надо исправить. ИМХО.

Как-то так:

gdisk /dev/sdb

#затем:

r 

# r  recovery and transformation options (experts only), затем:

? 

#подсказка по командам, ну и затем, видимо(могу ошибаться,

# надо попробовать, например на виртуальной машине): 

e 

# e  load main partition table from disk (rebuilding backup)

p

# чтобы убедиться что все правильно и

w

# w - write table to disk and exit - если все ок или

q

# q - выход без сохранения изменений

Я обновлял, но с 9.2 до 9.3

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

Потом, поскольку для ISP Manager под FreeBSD кастомное ядро и freebsd-update неприминимо, внимательно пересобирал мир, особенно на этапе mergemaster, чтобы не затереть конфигурационные файлы. После перезагрузки все завелось.

Если у вас порты не в актуальном состоянии, то сначала нужно обновить их, опять же, внимательно читая /usr/ports/UPDATING , контролируя работоспособность панели.

Т.е. задача требует времени и внимания. При этом, даже если все пойдет как по маслу, какое-то время сервер будет недоступен.

Попробуйте fail2ban - достаточно эффективная штука.