Игорь С

Вошло уже в привычку самому отвечать на свои же вопросы.
Не знаю на сколько это "грязный хак", но вот что я сделал:
1. переименовываем каталог .glusterfs
2. меняем аттрибуты каталога brick setfattr -x trusted.glusterfs.volume-id /brick_path; setfattr -x trusted.gfid /brick_path
3. Создаём новый volume с этим бриком
4. ОБЯЗАТЕЛЬНО выставляем все флаги, какие были указаны у умершего volume (например у меня были включеныfeatures.shard: on
features.shard-block-size: 512MB
которые я не учёл, и не мог понять, почему репа пустая)
5. Стартуем volume
6. Останавливаем volume
7. Останавливаем демон gluster (не уверен в необходимости)
8. Перемещаем старый .glusterfs (который мы переименовывали в пункте 1) обратно
9. Стартуем демона, volume и радуемся жизни

Сам спросил, сам отвечу. Необходимо NGINX сказать, что при нахождении /i дальше не спускаться. Делается это методом

location ^~ /i{
    proxy_pass ......
}

Читайте маны господа

Салют, я конечно могу быть не прав, но в официальном мануале https://certbot.eff.org/docs/using.html чётко написано

nginx: Very experimental and not included in certbot-auto.

В общем, я понял, что лучшим вариантом, будет подготовить конфиг "по проще", но с нужными мне фичами, и тиражировать его на сервера

В общем не знаю, нашли ли вы решение, я нашёл.
Суть в том, что каждая из Job - самостоятельная единица, которая создаёт для себя отдельный счётчик в каталоге. То есть

Job {
  Name = "Backup Desig DIFF"
...
}

Ничего не знает, о том, что сделал

Job {
  Name = "Backup Desig FULL"
...
}

Даже, не смотря на то, что они используют общий Volume. Суть работы бекапа заключается в том, что мы должны для одного Job описать как и куда он будет делать бекапы разных типов. Вот к чему пришёл я

Job {
  Name = BareosConfBackup
  Client = gazer-fd
  Type = Backup
  Level = Incremental
  Pool = IncBareBup
  Full Backup Pool = FullBareBup                 # Раз
  Differential Backup Pool = DiffBareBup     # Два
  Incremental Backup Pool = IncBareBup     # Три
  File Set = BConfig
  Schedule = WeeklyCycle
  Priority = 10
  Write Bootstrap = "/var/lib/bareos/%c.bsr"
  Messages = Standard
}

Schedule {
  Name = WeeklyCycle
  Run = Level = Full 1st sun at 23:00                        # Раз
  Run = Level = Differential 2nd-5th sun at 23:00     # Два
  Run = Level = Incremental mon-sat at 23:00          # Три
}

Получаем, что это задание, каждый первый понедельник каждого месяца делает полный бекап, со второго по пятый понедельник делает Diff, и каждую неделю с понедельника по субботу делает Incr
А что бы запустить это задание в консоли с определённым уровнем, нужно запускать его так

run job=XXX level=Full #{Differential, Incremental  и тд}

вот как-то так.

Сам спросил, сам отвечу

*update volume=Full-0001 
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: InChanger Flag
    10: Volume Files
    11: Pool
    12: Volume from Pool
    13: All Volumes from Pool
    14: All Volumes from all Pools
    15: Enabled
    16: RecyclePool
    17: Action On Purge
    18: Done
Select parameter to modify (1-18): 1
Updating Volume "gazer-fd_Full_TestPool.2016-05-25-19-08"
Current Volume status is: Used
Possible Values are:
     1: Append
     2: Archive
     3: Disabled
     4: Full
     5: Used
     6: Cleaning
     7: Read-Only
Choose new Volume Status (1-7): 5

Проблема оказалась в FirewallD. В виду специфики его работы (или моей криворукости) доступ к внешнему интерфейсу был разрешён только из сети 172.16.18.0/24 о чём свидетействовало правило

-A FORWARD -d 172.16.18.0/24 -i eth0 -o eth1 -j ACCEPT
-A FORWARD -s 172.16.18.0/24 -i eth1 -o eth0 -j ACCEPT

При этом, если попробовать добавить direct-rule

ipv4 filter FORWARD 0 -i eth0 -o eth1 -d 172.16.4.0/24 -j ACCEPT
ipv4 filter FORWARD 0 -i eth1 -o eth0 -s 172.16.4.0/24 -j ACCEPT

то они не отрабатывали (почему-то).
Заработало только после ручного вмешательства, что не очень хорошо, хотя и пока не критично

iptables -I FORWARD 1 -d 172.16.4.0/24 -i eth0 -o eth1 -j ACCEPT
iptables -I FORWARD 1 -s 172.16.4.0/24 -o eth0 -i eth1 -j ACCEPT

В общем, благодаря неоценимому вкладу Александр Карабанов нам удалось понять в чём проблемма.
для себя я написал скрипт, где прописываются нужные роуты и добавляются вышеописаные правила

Проблема оказалась в FirewallD. В виду специфики его работы (или моей криворукости) доступ к внешнему интерфейсу был разрешён только из сети 172.16.18.0/24 о чём свидетействовало правило

-A FORWARD -d 172.16.18.0/24 -i eth0 -o eth1 -j ACCEPT
-A FORWARD -s 172.16.18.0/24 -i eth1 -o eth0 -j ACCEPT

При этом, если попробовать добавить direct-rule

ipv4 filter FORWARD 0 -i eth0 -o eth1 -d 172.16.4.0/24 -j ACCEPT
ipv4 filter FORWARD 0 -i eth1 -o eth0 -s 172.16.4.0/24 -j ACCEPT

то они не отрабатывали (почему-то).
Заработало только после ручного вмешательства, что не очень хорошо, хотя и пока не критично

iptables -I FORWARD 1 -d 172.16.4.0/24 -i eth0 -o eth1 -j ACCEPT
iptables -I FORWARD 1 -s 172.16.4.0/24 -o eth0 -i eth1 -j ACCEPT

В общем, благодаря неоценимому вкладу Александр Карабанов нам удалось понять в чём проблемма.
для себя я написал скрипт, где прописываются нужные роуты и добавляются вышеописаные правила

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

потому, что второй слот может быть просто не распаян, так бывает на некоторых "компактных ноутбуках". Ещё в некоторых моделях оперативку распаивают прям на мать, но как видно это не ваш случай

getpass