Я не таскаю закрытый ключ на промежуточную машину. Прыжок для меня — дырка в TCP, не второй дом для ssh-agent. Ниже — чем ProxyJump отличается от проброса агента, когда агент всё-таки оставляю, и чем проверяю, что ключ с ноутбука никуда не уехал.

Хосты в примерах вымышленные: jump.example.net (документационный 203.0.113.40), внутренний prod-web-01.internal, пользователь ops. Свои имена и ключи подставляйте, чужие из чатов не копируйте.

Две привычки, которые путают с «удобным прыжком»

Первая: положить тот же закрытый ключ на bastion. «Ну я же сам туда захожу, чего его беречь». Bastion — это машина, на которую смотрит интернет. На ней чаще стоят общие учётки, старый sudo, чужой tmux. Если ключ от прода лежит файлом в ~/.ssh на такой коробке, компрометация прыжка равна компрометации всего, куда этот ключ пускают. Пароль на ключ тут слабое утешение: его снимут вместе с файлом, из памяти агента или из вашей же сессии.

Вторая: ForwardAgent yes глобально в ~/.ssh/config или в системном ssh_config. Так делают, чтобы со прыжка открыть следующий ssh «как с ноутбука». Удобно. И ровно поэтому опасно. На время сессии на джампе появляется unix-сокет агента. Любой, кто может читать этот сокет — root, ваша скомпрометированная учётка, чужой процесс под тем же uid — может пользоваться ключами, пока вы онлайн. Ключ с диска не копировали. Подпись от вашего агента уже достаточно.

Есть ещё гибрид: ключ на ноутбуке, а на прыжок его один раз залили «на всякий случай» и забыли. Потом ротировали ключ дома, на джампе старый остался. Я такие находки встречаю чаще, чем хотелось бы: ls -l ~/.ssh на bastion и два id_*, один из которых уже «не наш».

Что именно делает агент, когда его пробросили

ssh-agent на ноутбуке — нормальная вещь. Он держит расшифрованные ключи в памяти, чтобы не тыкать passphrase на каждый git fetch. Плохо не агент. Плохо отдавать его сокет чужой машине.

При ForwardAgent yes клиент поднимает на удалённой стороне канал и выставляет SSH_AUTH_SOCK. Дальше ssh prod-web-01, запущенный уже на прыжке, ходит в этот сокет. Подпись делает ваш ноутбук. Выглядит безопасно: «ключ же дома». Но решение «подписать вот этот challenge» принимает процесс на bastion. Если bastion врет, вы подпишете не то соединение, о котором думаете.

Практическая картинка, которую я показываю заказчику:

• Вы в сессии на jump.example.net.
• echo $SSH_AUTH_SOCK даёт путь вроде /tmp/ssh-XXXX/agent.1234.
• С правами на этот сокет можно сделать ssh-add -L и увидеть ваши ключи.
• Дальше — обычный ssh ops@prod-web-01.internal. Прод видит ваш ключ. В authorized_keys это тот же самый ключ, которым вы заходите «сами».

Root на джампе для этого не всегда нужен. Достаточно вашей же утёкшей сессии, crон-скрипта под тем же uid или «временного» бинарника в $PATH. Поэтому фраза «ну у нас же на bastion только свои» меня не греет: свои тоже ошибаются, а агент не спрашивает, кто именно попросил подпись.

Отдельно: ssh-add -c на ноутбуке чуть лучше, чем голый агент. Перед каждой подписью всплывает confirm. Это не броня, но если сокет увели тихо, вы хотя бы увидите лишний запрос в момент, когда сами ничего не открывали.

ProxyJump: прыжок без вашего ключа на той стороне

ProxyJump (ключ -J) делает другое. Клиент на ноутбуке открывает ssh на bastion и просит его прокинуть TCP до цели. Аутентификация на prod-web-01 идёт с ноутбука, напрямую в этом тоннеле. На прыжке нет вашего закрытого ключа, нет сокета агента, нет второго ssh от вашего имени.

Грубо: bastion видит, что с вашего IP пришёл ssh и что вы попросили соединиться с prod-web-01:22. Bastion не видит, каким ключом вы представились проду, и не может этот ключ переиспользовать через минуту после того, как вы отключились.

Минимальный ~/.ssh/config, с которого я начинаю:

Host jump
    HostName jump.example.net
    User ops
    IdentityFile ~/.ssh/id_ed25519_jump
    IdentitiesOnly yes
    ForwardAgent no

Host prod-web-01
    HostName prod-web-01.internal
    User ops
    ProxyJump jump
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ForwardAgent no

Два ключа — не паранойя. Ключ на интернет-джамп я считаю расходным: его проще отозвать. Ключ на прод на прыжок не кладу и в агент для сессии на jump не пихаю, если можно не пихать. IdentitiesOnly yes обязателен: иначе клиент переберёт все ключи из агента, и вы сами не вспомните, чем открыли хост. Плюс лишние попытки ключей иногда заканчиваются Too many authentication failures.

Одноразово без конфига:

ssh -J ops@jump.example.net ops@prod-web-01.internal

Два и больше прыжка — список через запятую:

ssh -J jump.example.net,dmz-gw.example.net ops@prod-web-01.internal

В конфиге то же самое: ProxyJump jump,dmz-gw. Старый ProxyCommand ssh -W %h:%p jump я оставляю только там, где клиент древний и ProxyJump ещё нет. Смысл тот же: проброс TCP, не проброс агента.

Как я проверяю, что агент не уехал

После захода на цель смотрю три вещи, не «ну вроде работает».

На ноутбуке, до входа:

ssh -G prod-web-01 | egrep -i 'proxyjump|proxycommand|forwardagent|identityfile|identitiesonly'

Хочу увидеть свой ProxyJump, forwardagent no, нужные IdentityFile и identitiesonly yes. Если forwardagent yes приехало из /etc/ssh/ssh_config или из Host * в конце файла — чиню там, а не добавляю ещё один Host выше, который потом перебьют.

Вход с отладкой:

ssh -v prod-web-01 2>&1 | egrep -i 'proxy|jump|forwarding|agent|Offering|Authentication succeeded'

Ищу, что клиент идёт через jump и что нет строк про agent forwarding. «Offering public key» должно относиться к ключу прода, не к ключу джампа. Если клиент предлагает пять ключей подряд — IdentitiesOnly не сработал.

На самой цели и на прыжке, уже внутри сессии:

echo "SSH_AUTH_SOCK=${SSH_AUTH_SOCK:-}"
ssh-add -l

На prod-web-01 при чистом ProxyJump сокет агента обычно пустой, ssh-add -l отвечает, что агента нет. На прыжке при обычном заходе на сам jump — то же самое, если я не просил проброс. Если сокет вдруг есть, а я его не включал, ищу кто: Host *, Include-info в конфиге, обёртка вроде assh/sshpass, корпоративный «улучшатель» ssh.

Ещё одна проверка, которую люди пропускают: ключи на диске прыжка.

ls -l ~/.ssh
find ~/.ssh -type f \( -name 'id_*' -o -name '*.pem' \) ! -name '*.pub'

Закрытых ключей там быть не должно. Если есть — снимаю с машины, смотрю authorized_keys на проде, не торчит ли тот же pubkey, и ротирую. Pubkey на прыжке (чтобы вы сами на него заходили) — нормально. Приватник от прода — нет.

Когда агент всё-таки нужен — и как его не размазать

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

• С удалённой машины нужно сходить в git по SSH вашим ключом, а ключ на эту машину класть нельзя. Тогда агент — меньшее зло, чем файл в ~/.ssh.
• Старый сценарий, который сам делает ssh со прыжка на пачку хостов и не умеет ProxyJump. Это чинят, но не в пять минут посреди инцидента.
• Промежуточный хост должен подписать что-то ещё вашим ключом (редко, и я сначала пытаюсь перенести это действие на ноутбук).

Правило одно: агент включаю на конкретный Host, не на *. И только на время задачи.

Host git-build.internal
    HostName git-build.internal
    User ops
    ProxyJump jump
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ForwardAgent yes

На ноутбуке ключ в агент кладу с подтверждением:

ssh-add -c ~/.ssh/id_ed25519_prod

Сессию короче держу. После работы ssh-add -d этот ключ из агента. На прыжке в sshd_config я по возможности ставлю AllowAgentForwarding no — тогда даже ошибочный ForwardAgent yes у клиента не поднимет сокет. Если агент нужен на одну машину за прыжком, форвардинг агента разрешаю только там, не на bastion.

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

ansible_ssh_common_args: '-o ProxyJump=ops@jump.example.net'

или ansible_ssh_extra_args с тем же. Ключ остаётся на контрольной машине. Если вам «без ForwardAgent плейбук не едет», чаще виноват не Ansible, а то, что роли сами делают ssh/rsync/git уже на целевом хосте вашим ключом. Это другая задача: либо ключ деплоя на целевой машине, либо отдельный deploy key в git, либо вынести шаг на ноутбук.

Что должно быть на самом прыжке

Bastion я собираю скучно. Чем меньше на нём живёт, тем меньше соблазна «раз уж зашли, давайте тут ключи».

• Отдельный ключ только для входа на jump. Этот ключ не пускает на прод.
• PermitRootLogin no, вход по паролю выключен, по возможности отдельный порт или хотя бы geo/fail2ban — как принято у заказчика, не догма.
• AllowTcpForwarding yes (иначе ProxyJump не взлетит), AllowAgentForwarding no, X11Forwarding no.
• Если sshd умеет PermitOpen — ограничиваю, куда вообще можно прыгать: только рабочие подсети, не «любой порт мира через нас».
• Нет общих ops с одним ключом на пятерых. Если ключ общий, вы не отзовёте одного человека.
• На диске нет id_* без .pub. Нет authorized_keys с ключами прода «для удобства».

Кусок sshd_config на прыжке, от которого я отталкиваюсь:

AllowAgentForwarding no
AllowTcpForwarding yes
X11Forwarding no
PermitTunnel no
GatewayPorts no
# если политика позволяет — режем направления:
# PermitOpen prod-web-01.internal:22 prod-db-01.internal:22

PermitOpen легко забыть и потом час ловить administratively prohibited. Сначала проверяю, что ProxyJump жив без него, потом сужаю. Логи sshd на прыжке смотрю не «красиво ли», а кто и куда просил forward: если из сессии ops вдруг полезли на адрес, которого в заявке не было, это уже не удобство, а инцидент.

Мелочи, из-за которых «прыжок не работает»

Частая жалоба: «с -J меня не пускает, а два ручных ssh работают». Почти всегда одно из трёх.

Первое — разные пользователи. На jump вы ops, на проде deploy, а в команде указали одного. В конфиге это два User. В -J — явно ops@jump и deploy@prod.

Второе — DNS. Ноутбук не резолвит prod-web-01.internal, а bastion резолвит. ProxyJump соединяет туда, куда сказал клиент. Если клиент не знает имя, пишу в HostName адрес, который виден с прыжка, либо завожу имя в локальный /etc/hosts только как метку. Обратная ловушка: в HostName поставили внешний IP прода, которого с прыжка нет — ручной второй ssh с jump шёл на внутреннее имя, а ProxyJump пытается в белый адрес.

Третье — ключи и агент. Клиент предлагает ключ джампа на прод, прод отвечает «не тот» несколько раз и отваливается. Лечится IdentitiesOnly и отдельным IdentityFile. Если ключ в агенте один, а файлов много, агент всё равно может предложить не то: поэтому для прод-хостов я указываю файл явно.

Четвёртое, реже: ControlMaster. Мультиплекс на jump удобен, но старый сокет иногда держит чужие опции. Если после правки конфига поведение «как раньше», сношу сокеты ~/.ssh/cm-* и проверяю ещё раз.

Что я отказываюсь считать решением

Не считаю решением скопировать закрытый ключ на bastion «только на время работ». Файл переживает работы. Его найдёт следующий, кто зайдёт под той же учёткой.

Не считаю решением глобальный ForwardAgent yes «потому что так в wiki». Wiki часто писали, когда ProxyJump ещё не было в клиенте по умолчанию. Сейчас клиент это умеет давно.

Не считаю решением один ключ на всё: ноутбук, jump, прод, git, CI. Отзыв после утечки тогда равен «перевыпустить жизнь». Два-три ключа с понятной ролью дешевле нервов.

Не считаю решением «у нас на джампе свои люди, нам не надо». Свои люди оставляют tmux, ставят тестировать бинарник, дают sudo на час. Агент в этот час работает на всех.

Считаю решением короткую схему, которую можно проговорить вслух: ключ прода живёт на ноутбуке, прыжок только прокидывает TCP, агент выключен, кроме одной явно названной машины, и на диске bastion нет ни одного id_* без суффикса .pub. Это скучно. Зато когда bastion однажды вскроют — а интернет-машину вскрывают — прод не откроется тем же ключом из чужой сессии.

Смотрю конфиг — почти всегда одно и то же. На пире стоит AllowedIPs = 0.0.0.0/0 «чтобы точно работало», DNS прописан 8.8.8.8, на VPS ip_forward выключен, а проверку сделали командой ping 10.66.66.1. Пинг до адреса туннеля проходит. Это доказывает только то, что два пира видят друг друга. Это не доказывает, что рабочий трафик идёт в туннель, что DNS не утекает мимо, и что обратный путь из офисной сети существует.

Ниже — как я собираю офис VPS так, чтобы маршруты, DNS и split-tunnel не врали, и чем проверяю, что пакет реально ушёл в wg0, а не красиво показал handshake в wg show. Без «поставьте GUI» и без схемы «все в 0.0.0.0/0 и будет счастье».

Два разных туннеля, которые путают в одном конфиге

Мне на стол приносят три задачи, и их пытаются решить одним [Peer]:

• С ноутбука в офисе ходить на сервисы на VPS: SSH, панель, приватный git, админка, которая слушает только внутренний адрес.
• С VPS ходить в офисную сеть: NAS, принтер, контроллер, камера, которой «интернет не нужен».
• Выгнать весь офисный интернет через VPS, «чтобы как на работе».

Это не один туннель с разными галочками. Это разный AllowedIPs, разный форвардинг и разный DNS. Первые две задачи я почти всегда делаю split-tunnel: в туннель уезжает только нужная подсеть. Третья — полный туннель, и за неё отдельно платят CPU, трафиком и сломанным Zoom, если MTU не поправили.

Адреса в примерах ниже документационные, не боевые. Публичный VPS — 203.0.113.10, белый офиса — 198.51.100.20, туннель — 10.66.66.0/24, LAN офиса — 192.168.40.0/24. Свои цифры подставьте, чужие из интернета не копируйте вместе с ключами.

AllowedIPs — это маршрут, а не «список друзей»

В WireGuard AllowedIPs делает две вещи сразу. Снаружи это криптоключ: пакет с таким источником примут только от этого пира. Изнутри wg-quick по этому списку ставит маршруты. Написали 0.0.0.0/0 — получите дефолт через туннель (у wg-quick ещё и отдельная таблица, обычно 51820). Написали 10.66.66.0/24 — в туннель пойдёт только эта сеть.

Поэтому «handshake есть, а сайт на VPS открывается по белому IP» — нормально для split-tunnel и баг, если вы хотели полный туннель. Браузер пошёл на 203.0.113.10 напрямую, UDP 51820 при этом живой. Туннель тут ни при чём.

Смотрю, что система думает про маршрут, не что написано в комментарии к конфигу:

wg show
ip -4 addr show dev wg0
ip -4 route show
ip -4 route show table all | grep -E 'wg0|51820'
ip -4 route get 10.66.66.1
ip -4 route get 203.0.113.10
ip -4 route get 8.8.8.8

ip route get врёт меньше, чем ощущения. Если до внутреннего адреса VPS маршрут не через wg0, дальше можно не гадать — трафик в туннель не собирался.

Split-tunnel: офис ходит на VPS, интернет офиса не трогаем

Это тот вариант, который я ставлю по умолчанию. Офисный пир (ноутбук или маленький шлюз) держит туннель, в AllowedIPs только сеть туннеля и, если надо, приватные сети на стороне VPS. Исходящий веб офиса идёт как раньше, через местного провайдера.

VPS:

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <ключ VPS>

[Peer]
PublicKey = <ключ офиса>
AllowedIPs = 10.66.66.2/32

Офис (за NAT, поэтому keepalive):

[Interface]
Address = 10.66.66.2/24
PrivateKey = <ключ офиса>

[Peer]
PublicKey = <ключ VPS>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24
PersistentKeepalive = 25

Если на VPS сервисы торчат в docker-сети или во втором внутреннем интерфейсе, в AllowedIPs офиса добавляю эту сеть, не «весь мир». И на VPS тогда уже нужен форвардинг и фильтр, иначе пакет дойдёт до ядра и умрёт в FORWARD.

На VPS для split-tunnel NAT наружу обычно не нужен. Нужен, когда офис должен ходить не на сам VPS, а через него дальше. Пока задача «SSH на 10.66.66.1» — без маскарада.

PersistentKeepalive = 25 ставлю на том конце, который за NAT или с динамическим белым. Без него UDP-маппинг у провайдера офиса схлопывается, handshake в wg show становится старше пары минут, и «туннель встал сам» ровно до первой попытки зайти с другой стороны.

Когда VPS должен видеть LAN офиса

Вторая заявка: бэкап с VPS на NAS, мониторинг контроллера, SSH на станок, который «в интернет не смотрит». Тогда на стороне VPS в пире офиса мало /32 туннельного адреса. Нужна офисная подсеть:

# на VPS, peer = офисный шлюз
[Peer]
PublicKey = <ключ офисного шлюза>
AllowedIPs = 10.66.66.2/32, 192.168.40.0/24

Офисный шлюз должен форвардить. Это уже не «WireGuard на ноутбуке бухгалтера». Ноутбук не маршрутизатор: пакет с VPS на 192.168.40.15 дойдёт до ноутбука и останется там, NAS его не увидит, а ответ NAS пойдёт в локальный шлюз офиса и умрёт, потому что шлюз про 10.66.66.0/24 ничего не знает.

На шлюзе офиса:

sysctl -w net.ipv4.ip_forward=1
# постоянное место — /etc/sysctl.d/, не «в сессии до ребута»

iptables -C FORWARD -i wg0 -o eth0 -s 10.66.66.0/24 -d 192.168.40.0/24 -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i wg0 -o eth0 -s 10.66.66.0/24 -d 192.168.40.0/24 -j ACCEPT
iptables -C FORWARD -i eth0 -o wg0 -s 192.168.40.0/24 -d 10.66.66.0/24 -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i eth0 -o wg0 -s 192.168.40.0/24 -d 10.66.66.0/24 -j ACCEPT

Имена интерфейсов свои. eth0 в статье — заглушка. На машине смотрю ip -br link, не копирую с чужого скриншота.

Обратный маршрут в LAN часто забывают. NAS отвечает на запрос с 10.66.66.1 через дефолтный шлюз офиса. Шлюз этот пакет не ждал — в лучшем случае дроп, в худшем NAT в интернет. Варианты, которые работают:

• Статический маршрут на роутере офиса: 10.66.66.0/24 via 192.168.40.2, где .2 — шлюз с WireGuard.
• Или маскарад на офисном WG-хосте в сторону LAN, если роутер трогать нельзя. Работает, в логах NAS все запросы с одного адреса шлюза. Для бэкапа терпимо, для разбора «кто стучится» — нет.

Пересечение подсетей ловлю сразу. Офис на 192.168.1.0/24, docker на VPS тоже 192.168.1.0/24 — туннель поднимется, маршруты будут врать по очереди. Одну из сетей надо сменить. Спорить, «чья 192.168.1 важнее», бесполезно: важнее та, которую проще перенумеровать.

Полный туннель: 0.0.0.0/0, таблица 51820 и NAT на VPS

AllowedIPs = 0.0.0.0/0 на офисном пире означает: весь IPv4, кроме того что wg-quick сам вычтет для Endpoint, должен идти в туннель. wg-quick для этого поднимает policy routing, не просто ip route add default. Поэтому «я убрал default из main, а туннель живой» — ещё не победа. Смотреть надо ip rule и таблицу, которую создал WireGuard:

ip rule
ip route show table 51820
ip route get 8.8.8.8
ip route get 203.0.113.10

До Endpoint маршрут обязан остаться в физический интерфейс. Иначе туннель пытается нести сам себя и тихо умирает после первого же пересчёта маршрутов.

На VPS для чужого интернета нужны три вещи, не одна:

• net.ipv4.ip_forward=1
• NAT с туннеля в внешний интерфейс, иначе провайдер VPS не пропустит чужие RFC1918 как source
• FORWARD в файрволе в обе стороны, не только INPUT на 51820/udp

# на VPS, внешний интерфейс уточнить: ip -br addr
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -C POSTROUTING -s 10.66.66.0/24 -o ens3 -j MASQUERADE 2>/dev/null || \
iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o ens3 -j MASQUERADE

iptables -C FORWARD -i wg0 -o ens3 -j ACCEPT 2>/dev/null || iptables -A FORWARD -i wg0 -o ens3 -j ACCEPT
iptables -C FORWARD -i ens3 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i ens3 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Правила в статье — эскиз под iptables. На машине с nftables я пишу в ту таблицу, которая уже живая, а не добавляю второй файрвол «рядом». ufw route allow и iptables -A FORWARD одновременно — классический способ получить «у меня же разрешено», когда пакет режет другая цепочка.

Полный туннель я не ставлю «на всякий случай». Он нужен, когда офисный канал дырявый, нужен выход с фиксированного белого VPS, или политика «весь трафик только через нас». Для доступа к одной админке на VPS это дорогой способ сломать DNS, MTU и чужой Zoom.

DNS: туннель живой, а имена резолвятся мимо

Самая частая ложь после wg show. Туннель есть, curl https://10.66.66.1 работает, а curl https://panel.internal идёт неизвестно куда или не идёт вовсе. Причина почти всегда в резолвере, не в маршрутах.

DNS = в wg-quick — не магия. На systemd-resolved это попытка прикрутить домены к интерфейсу. На машине без resolved это может записаться в /etc/resolv.conf и затереть офисный DNS. На Windows-клиенте это отдельная история с «использовать DNS этого адаптера». Я не верю строке в конфиге, пока не увижу, куда реально уходит запрос.

Проверка с офисного пира:

resolvectl status
resolvectl query panel.internal
getent hosts panel.internal

# куда уходит UDP/53, пока стучите в имя
tcpdump -ni wg0 port 53
tcpdump -ni eth0 port 53

Если дамп на физическом интерфейсе показывает запросы на 8.8.8.8, а на wg0 тихо — split-tunnel сделал ровно то, что вы написали: маршрут до публичного DNS прямой. Внутреннее имя при этом либо не резолвится, либо резолвится в публичный адрес, и вы снова обходите туннель.

Рабочая схема для split-tunnel, которой я пользуюсь:

• На VPS крутится DNS, который знает внутренние имена. Слушает 10.66.66.1, не 0.0.0.0 в интернет.
• У офисного пира DNS = 10.66.66.1, и этот адрес уже входит в AllowedIPs.
• Если нужен только суффикс internal, в resolved указываю домен на интерфейс туннеля, а не подменяю весь резолвер офиса.

Для полного туннеля публичный DNS тоже должен быть достижим через туннель. Иначе получаете курицу и яйцо: чтобы поднять туннель, нужен DNS Endpoint, а DNS вы уже отправили в туннель, которого нет. Поэтому Endpoint я пишу IP, не именем. Имя в Endpoint оставляю только там, где белый VPS прыгает и без DNS туннель не собрать — тогда DNS офиса должен резолвить этот хост до подъёма wg0.

IPv6 утекает отдельно, MTU ломает «сайты открываются через раз»

Настроили IPv4, про IPv6 забыли. Браузер берёт AAAA, пакеты идут мимо туннеля в родной канал. curl -4 при этом красивый. Если полный туннель — в AllowedIPs нужен и ::/0, и на VPS форвардинг/NAT6, либо IPv6 на офисном пире надо выключить осознанно, не «само как-нибудь».

Для split-tunnel я проверяю оба стека:

ip -6 route get 2001:db8::1
curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Документационный 2001:db8::1 в route get нужен, чтобы увидеть, в какой интерфейс ядро отправит «чужой» v6. Если полного туннеля нет, прямой маршрут — ожидаемо. Если полный туннель заявлен, а v6 уходит в eth0 — дыра.

MTU. UDP + WireGuard + внешний Ethernet обычно просит 1420, на части каналов — ниже. Симптом не «туннель мёртв», а «SSH живой, HTTPS висит, крупные POST отваливаются, мессенджеры отваливаются на картинках». Ловлю так:

ip link show wg0
ping -M do -s 1372 10.66.66.1
ping -M do -s 1200 10.66.66.1

Если 1372 с DF не проходит, опускаю MTU на wg0, пока не начнёт. На VPS с jumbo или с PPPoE за NAT цифры другие — подбираю, не копирую 1280 «потому что все так пишут», если канал нормально держит больше.

Проверка, что рабочий трафик в туннеле, а не только handshake

Чеклист, которым я пользуюсь после wg-quick up. По порядку, не выборочно.

# 1. пир живой
wg show
# handshake секунды-минуты, не часы; transfer растёт, когда вы сами генерируете трафик

# 2. адрес и маршрут
ip route get 10.66.66.1
# ожидаю dev wg0

# 3. ICMP внутри туннеля — необходимое, но не достаточное
ping -c 3 10.66.66.1

# 4. TCP на сервис, который слушает только внутренний адрес
curl -v --connect-timeout 5 http://10.66.66.1:8080/
ss -tlnp | grep 8080   # это уже на VPS: сервис не на 0.0.0.0:80 случайно?

Дальше — дамп. Это единственный способ перестать спорить. На офисном пире в одном окне генерирую трафик, в двух других:

tcpdump -ni wg0 host 10.66.66.1
tcpdump -ni eth0 udp port 51820
tcpdump -ni eth0 host 203.0.113.10 and not udp port 51820

Нормальная картина split-tunnel, когда я хожу на внутренний сервис: на wg0 видны пакеты до 10.66.66.1, на физическом интерфейсе до VPS — только UDP 51820. Если на физическом интерфейсе всплыл обычный TCP на белый 203.0.113.10:443, вы открыли публичный nginx, не туннель.

Для полного туннеля добавляю:

# с офисного пира
curl -4 -s https://ifconfig.me
# должен вернуться белый VPS, не белый офиса

ip route get 1.1.1.1
# dev wg0 или таблица 51820, не eth0

tcpdump -ni eth0 tcp port 443
# во время curl на внешний сайт здесь не должно быть голого TCP
# только UDP 51820

Если ifconfig.me показал белый офиса — трафик мимо. Если показал белый VPS, но на eth0 всё равно виден TCP 443 — смотрю второй интерфейс, IPv6, браузерный DoH, «умный» антивирус со своим туннелем. Бывает, что curl в туннеле, а Firefox живёт своей жизнью.

На самой VPS в это время:

tcpdump -ni wg0
tcpdump -ni ens3 udp port 51820
# conntrack, если ping есть, а TCP нет
conntrack -L | grep 10.66.66

Ещё одна ловушка: сервис на VPS слушает 127.0.0.1 или только публичный адрес. Туннель доставляет пакет на 10.66.66.1, nginx его не принимает. Это не «WireGuard сломался». Это ss -tlnp до настройки туннеля, не после.

Что я проверяю, когда «подключилось, но не работает»

Короткий разбор по симптомам, без перебора всего man.

• Handshake старше нескольких минут, transfer ноль — NAT, файрвол хостера на UDP 51820, неверный Endpoint, часы сильно разъехались реже, но бывает. С офиса: nc -u -v 203.0.113.10 51820 ничего не доказывает (UDP без ответа), нужен дамп на VPS в момент wg-quick up.
• Handshake живой, ping до 10.66.66.x нет — AllowedIPs не покрывает адрес, или адреса туннеля пересеклись у двух пиров. Два клиента с 10.66.66.2/24 одновременно — классика копипаста.
• Ping есть, TCP нет — MTU, или сервис не слушает адрес туннеля, или FORWARD/фильтр режет не ICMP, а tcp.
• До VPS по внутреннему IP есть, до NAS в офисе нет — на VPS в AllowedIPs нет LAN, на офисе нет forward, на роутере офиса нет обратного маршрута.
• Браузер открывает сайт по домену «не туда» — DNS мимо туннеля или A-запись смотрит на белый, а вы думали, что ходите внутрь.
• После сна ноутбука туннель «есть», трафика нет — keepalive, stale UDP mapping, помогает wg-quick down; wg-quick up, а постоянно — keepalive и иногда NetworkManager dispatcher, не вечная сессия с 2023 года.

Ключи и чужие IP в тикет не кладу. В логах для разбора достаточно последних байт публичного ключа из wg show и документационных адресов. Боевой Endpoint заказчика в статью и в переписку с подрядчиком не тащу.

Что оставляю в конфиге, когда уже заработало

Минимальный набор, который я не выкидываю «потом допишем»:

• Endpoint только IP, порт явно 51820 или тот, что реально открыт у хостера. У части облаков UDP на дефолтном порту режут, тогда слушаю другой и это же пишу в Endpoint.
• AllowedIPs по задаче, не максимальный. Split-tunnel — сети, которые правда надо унести. Полный туннель — осознанный 0.0.0.0/0 плюс IPv6-решение.
• PersistentKeepalive на NAT-стороне.
• DNS только тот, который достижим через получившиеся маршруты.
• Проверка дампом один раз после подъёма, не «пинг прошёл — закрываем задачу».

Конфиг без этой проверки — это VPN на скриншоте. Скриншот wg show с handshake я в отчёт тоже прикладываю, но рядом кладу ip route get до рабочего адреса и кусок tcpdump, где видно UDP 51820 снаружи и целевой трафик внутри. Если второго нет, туннеля для работы тоже нет — есть только красивый интерфейс wg0.

Смотрю du -xhd1 /var и почти всегда в топе /var/log. Внутри него не nginx/access.log на первом месте, а /var/log/journal на гигабайты. Хостер предлагает «расширить диск». Расширять можно, но это не лечение: journald по умолчанию считает нормальным занять десятую часть файловой системы. На маленьком корне это уже не «логи», это треть полезного места.

Ниже — как я отличаю «журнал имеет право быть большим» от «он просто не ограничен», чем persistent отличается от volatile на практике, и что смотреть утром, если ночью диск дошёл до нуля. Без советов вида «поставьте плагин» и без удаления файлов наугад.

Где journald вообще пишет, и почему каталог внезапно появляется

У systemd-journald два реальных места на диске (точнее, на диске и в tmpfs):

• /run/log/journal — volatile, живёт в памяти/tmpfs, после ребута пусто.
• /var/log/journal — persistent, переживает перезагрузку.

Режим задаётся в /etc/systemd/journald.conf параметром Storage=. По умолчанию почти везде auto: если каталог /var/log/journal существует — пишем туда и храним между ребутами. Нет каталога — сидим в /run.

Это ловушка, на которую люди наступают сами. На «голом» облачном образе журнал был volatile, места хватало. Кто-то из документации скопировал mkdir -p /var/log/journal «чтобы логи не терялись», перезапустил systemd-journald — и auto молча стал persistent. Лимиты при этом никто не ставил. Через неделю диск красный.

Проверяю так:

df -h / /var /run
du -sh /var/log/journal /run/log/journal /var/log 2>/dev/null
journalctl --disk-usage
ls -ld /var/log/journal
systemd-analyze cat-config systemd/journald.conf

journalctl --disk-usage говорит, сколько journald сам считает занятым. du — сколько видит файловая система. Если они сильно расходятся, смотрю разреженные файлы и «хвосты» после неудачного vacuum: du -sh --apparent-size /var/log/journal рядом с обычным du -sh.

Почему «дефолт 10%» на VPS — уже инцидент

В man у journald это звучит безобидно: SystemMaxUse по умолчанию — около 10% файловой системы, с потолком 4G; SystemKeepFree — около 15% свободными. На корне в 40G это до четырёх гигабайт журнала. На корне в 20G — те же проценты, только больнее.

Четыре гигабайта логов на виртуалке, где сам сайт весит 800 мегабайт, — не «запас на разбор». Это место, которое ночью отъест MySQL, очередь почты или бэкап.

Важная оговорка: лимиты — не жёсткая квота в момент записи каждой строки. Journald ротирует и чистит архивные файлы, когда доходит до порога. Активный system.journal так просто не схлопнется. Если диск уже 100%, vacuum может не стартовать нормально, потому что некуда дописать ротацию. Классический труп: раздел полный, journald не вакуумит, сервисы не пишут, SSH на ключах ещё жив, потому что сессия старая.

Поэтому на маленьком VPS я не оставляю дефолт. Дефолт рассчитан на машину, где /var не равен всему диску, и где гигабайды логов — нормальная цена за историю.

Persistent vs volatile: это про утро после ребута, не про вкус

Volatile соблазнительно прост: ребутнул — логи кончились, диск не раздувается. Я так оставляю только там, где журнал всё равно уезжает на внешний syslog и локальная история после ребута не нужна. На обычном VPS с сайтом это почти никогда не тот случай.

Типичный ночной сценарий: в 03:14 гипервизор переехал, ядро поймало OOM, сработал watchdog хостера, или сам systemd ушёл в reboot после failed unit. Утром вам нужен предыдущий бут. Он берётся так:

journalctl --list-boots
journalctl -b -1 -p err..alert --no-pager
journalctl -b -1 -u ssh -u nginx -u php-fpm -u mysql --no-pager | tail -n 200

Если Storage=volatile, после ребута -b -1 пустой. Вы будете гадать по last reboot и по графику load у хостера. Это не диагностика, это гадание.

Persistent без лимита — другая крайность: история есть, но её некуда писать, потому что диск кончился самой историей.

Рабочая схема на VPS, которую я ставлю почти всегда: persistent, но маленький. История на несколько дней, не на квартал. Внешний syslog — если он уже есть; не вместо локального журнала, а поверх, чтобы переживать смерть самой машины.

Что смотреть overnight, пока диск ещё не ноль

Если диск уже 100% — сначала воздух, потом разбор. Если ещё есть 1–2 гигабайта, ночью я смотрю не «красивый dashboard», а четыре вещи.

Первое: это вообще journald или рядом лежит второй обжора. Часто параллельно толстеют /var/log от rsyslog, бинарные логи MySQL, json-file логи Docker. Journald виноватят первым, потому что путь незнакомый.

du -xhd1 /var /var/log /var/lib 2>/dev/null | sort -h
du -sh /var/lib/docker/containers 2>/dev/null
du -sh /var/lib/mysql 2>/dev/null
ls -lh /var/log/*.log /var/log/syslog /var/log/messages 2>/dev/null

Второе: журнал вырос за ночь или копился две недели. Смотрю даты файлов и размер активного относительно архивных:

ls -lhS /var/log/journal/*/* 2>/dev/null | head
journalctl --header | head -n 40

Архивные файлы с @ в имени — уже закрытые куски. Если за ночь вырос один свежий файл на гигабайт — это не «дефолтный 10%», это болтливый юнит. Если лежат десятки старых файлов по 300–400M — это никто никогда не ставил SystemMaxUse и не делал vacuum.

Третье: был ли ребут. journalctl --list-boots, who -b, last -x reboot | head. Если бут ночью был, первым делом journalctl -b -1 -p err, а не сегодняшний хвост. Сегодняшний хвост после ребута начинается с «диска мало» и маскирует причину.

Четвёртое: не забился ли /run. Volatile журнал живёт в tmpfs. На машине с 1–2 гигабайтами RAM /run маленький. Когда он полный, симптомы странные: не стартуют юниты, Failed to create ... No space left, при этом df -h / ещё живой. Смотрю df -h /run отдельно, всегда.

Кто орёт в журнал: без этого лимит только отодвинет взрыв

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

Счётчик по юнитам за ночь, без jq:

journalctl --since "6 hours ago" -o json --no-pager | python3 -c '
import sys, json, collections
c = collections.Counter()
for line in sys.stdin:
    try:
        j = json.loads(line)
    except Exception:
        continue
    key = j.get("_SYSTEMD_UNIT") or j.get("SYSLOG_IDENTIFIER") or "?"
    c[key] += 1
for k, v in c.most_common(20):
    print("%8d  %s" % (v, k))
'

На живой машине это может минуту помолчать — json тяжёлый. Если python3 жалко, грубее по short-формату:

journalctl --since "6 hours ago" --no-pager | awk '{print $5}' | sed 's/\[.*//' | sort | uniq -c | sort -nr | head

Пятое поле в short — не священная корова, на неанглийской локали колонки плывут. Для разбора лучше json.

Что обычно оказывается наверху, когда «за ночь съело диск»:

• systemd-таймер бэкапа с StandardOutput=journal и rsync -v / find на сотни тысяч файлов;
• fail2ban + ssh-парольный брут: одна попытка — несколько строк в journal и ещё дубль в auth.log;
• PHP/Node в debug, который кто-то включил «на час» в пятницу;
• сетевой юнит, который рестартует в цикле и каждый раз пишет stack trace;
• ядро и OOM-killer — это уже не болтовня, это авария, её резать лимитом журнала нельзя, её надо читать.

Для шумного, но не аварийного юнита правильнее прикрутить его вывод, а не бесконечно растить journal. В unit-файле: StandardOutput=append:/var/log/backup.log плюс logrotate, или убрать -v. RateLimit в journald.conf режет пачку одинаковых сообщений, но на бэкап с уникальными путями в каждой строке он почти не действует: burst исчерпывается, а диск всё равно пишется, пока не упрётся.

SystemMaxUse и соседние крутилки

Править лучше drop-in, а не жирный коммент в исходном journald.conf. Так видно, что меняли вы, а не пакет.

mkdir -p /etc/systemd/journald.conf.d
cat >/etc/systemd/journald.conf.d/size.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=200M
SystemKeepFree=1G
SystemMaxFileSize=50M
RuntimeMaxUse=50M
MaxRetentionSec=7day
MaxFileSec=1day
Compress=yes
EOF
systemctl restart systemd-journald
journalctl --vacuum-size=200M --vacuum-time=7d
journalctl --disk-usage

Зачем каждая строка, коротко.

Storage=persistent — явно, чтобы не зависеть от «кто-то случайно создал каталог». Каталог после этого должен существовать: mkdir -p /var/log/journal, права оставить journald самому поправить.

SystemMaxUse=200M — потолок persistent-журнала. На VPS с сайтом и ssh мне для разбора инцидента обычно хватает десятков–пары сотен мегабайт, не гигабайт. Если это шлюз, с которого разбирают неделю брутфорса по сырым логам — поставьте больше, но цифрой, не дефолтом.

SystemKeepFree=1G — не съедать последний гигабайт, даже если MaxUse ещё не достигнут. На маленьком корне это важнее MaxUse: MySQL и очередь почты должны иметь куда писать.

SystemMaxFileSize — чтобы один файл не вырос в весь лимит. Vacuum чистит архивные; огромный активный файл неудобно и vacuum, и копировать.

RuntimeMaxUse — потолок для /run, чтобы volatile не убил tmpfs.

MaxRetentionSec=7day — дефолт по времени почти не режет, живёт размер. Я хочу неделю, не «пока влезает 10% диска». Для разбора overnight недели хватает. Месяц уже про хранение, его лучше делать на syslog-коллекторе, не на корне VPS.

После рестарта journald файлы сами не схлопнутся до новой цифры в ту же секунду. Поэтому сразу --vacuum-size / --vacuum-time. Рестарт журналы не удаляет — это не rm.

Vacuum — не rm -rf, особенно когда диск уже 100%

Нормальный путь:

journalctl --disk-usage
journalctl --vacuum-size=100M
journalctl --vacuum-time=2d
journalctl --verify

--verify иногда находит битый хвост после внезапного отключения питания. Битый файл vacuum может обходить стороной, и место не отдаётся. Тогда смотрю имена в /var/log/journal/<machine-id>/ и убираю архивные *@*.journal / *.journal~, не трогая текущий system.journal.

Чего не делаю, пока есть другой выход: rm -rf /var/log/journal/* на живой системе. Один раз из ста это проходит, в остальные journald остаётся с открытыми inode, место не возвращается, а после рестарта вы получаете пустой журнал ровно в тот момент, когда хотели понять, почему диск кончился.

Аварийный порядок, если писать уже некуда:

• найти и удалить пару самых старых архивных файлов *@*.journal — это даёт воздух;
• сразу journalctl --vacuum-size=80M;
• поставить drop-in с лимитами и перезапустить journald;
• только потом искать болтливый юнит, иначе пока вы читаете json, диск снова забьётся.

Сигнал «почистись прямо сейчас» у journald — SIGUSR2. SIGUSR1 — сбросить буфер на диск, не vacuum. Путать их бессмысленно, но люди путают.

Двойной учёт: journald, rsyslog и Docker

На Debian/Ubuntu часто живы оба мира. journald пишет своё. rsyslog забирает через imjournal или сокет и пишет /var/log/syslog, /var/log/auth.log. Итого одна и та же неудачная попытка SSH лежит дважды. Rate-limit в journald на файлы rsyslog не действует.

Проверяю, не тащим ли мы дубль:

systemctl is-active rsyslog syslog-ng 2>/dev/null
grep -RInE 'imjournal|imuxsock|ForwardToSyslog' /etc/rsyslog.conf /etc/rsyslog.d /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
du -sh /var/log/journal /var/log/syslog /var/log/auth.log 2>/dev/null

ForwardToSyslog=yes плюс persistent journald — сознательное удвоение. Имеет смысл, если внешний разбор завязан на syslog-файлы, а journal вы хотите маленьким. Не имеет смысла, если никто эти файлы не читает, а logrotate на syslog стоит «weekly, rotate 8» и молча держит ещё сотни мегабайт.

Docker — отдельная яма. json-file драйвер пишет в /var/lib/docker/containers/.../*.log, это не journald. Человек чистит journal, диск не отходит, начинается шаманство. Если в du победил docker — лимиты в daemon.json (log-opts max-size), не в journald.conf. Путь другой, болезнь похожая.

Что я реально оставляю на маленьком VPS

Для обычного сайта (nginx, php-fpm, mysql, ssh) на одном диске:

• persistent, 150–300M потолок, неделя хранения;
• /run ограничен десятками мегабайт;
• таймеры бэкапа не пишут verbose в journal;
• если rsyslog нужен файлами для fail2ban — пусть живёт, но logrotate жёсткий, не дефолтный weekly на 100M файлах;
• внешний syslog — когда машин больше двух или когда хочется историю длиннее недели.

Volatile я ставлю на одноразовые тестовые машины и на те VPS, где журнал и так уезжает агентом, а локальный диск маленький и ребут не является загадкой.

И я не храню journal как бэкап логов. Это кольцевой буфер для разбора. Если лог должен жить три месяца «по требованиям», ему место не в /var/log/journal на корне.

Утренний чеклист, если ночью диск снова опух

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

• df -h / /run /var — какой именно раздел, не «диск вообще»;
• du -xhd1 /var — journal это или mysql/docker/бэкап;
• воздух: vacuum или пара архивных файлов, не apt и не /tmp;
• journalctl --list-boots и при ночном ребуте сразу -b -1 -p err;
• счётчик юнитов за ночь — кто писал, не «сколько процентов в SystemMaxUse»;
• drop-in с SystemMaxUse / SystemKeepFree, vacuum до новой цифры;
• проверка, что через час journalctl --disk-usage не ползёт обратно с той же скоростью.

Если после лимита журнал упирается в потолок каждые несколько часов — лимит сработал, но источник шума жив. Тогда это уже не настройка journald, а разбор конкретного юнита. Крутить SystemMaxUse вверх, «чтобы влезало», на маленьком VPS я не соглашаюсь: вы просто вернёте ту же заявку через неделю, только с более толстым журналом и снова нулём на диске.

--link-dest лежит между этими двумя дуростями. Каждый слепок выглядит как полный каталог: зашёл в /backup/site/2026-08-27/ — видишь весь сайт, как в тот день. На диске при этом лежат только изменившиеся файлы. Неизменные — hardlink на inode прошлого слепка. Это не магия файловой системы и не «инкремент в проприетарном формате». Это обычный ext4/xfs и обычный rsync. Именно поэтому я его до сих пор ставлю там, где не нужен Borg/restic со своими репозиториями, а нужен каталог, из которого файл можно просто скопировать.

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

Что именно делает –link-dest, без сказки про «инкремент»

Rsync сравнивает источник с каталогом назначения. Если файла в назначении ещё нет, он смотрит в каталог из --link-dest. Файл там есть, размер и mtime совпали — в новый слепок кладётся hardlink, байты заново не копируются. Файл изменился — в новый слепок пишется новая копия, старый inode остаётся в старом слепке.

Поэтому:

• каждый дневной каталог самодостаточный: ls, grep, cp работают как по живому дереву;
• место растёт примерно на объём изменений, а не на полный размер каждый день;
• удалили файл на проде — в новом слепке его нет (--delete), в старом он ещё лежит, пока слепок не выкинете.

Hardlink — это не копия и не симлинк. Два имени, один inode. Пока на inode есть хотя бы одна ссылка, данные живы. Выкинули самый старый слепок — unlink уменьшил счётчик, и только для тех файлов, которые больше ни в одном слепке не встречаются, место реально освободилось.

Важное следствие, из-за которого люди потом материются: правка файла внутри слепка правит все слепки, которые ссылаются на тот же inode. Бэкап — не рабочая копия. Залезли поправить «на всякий случай конфиг в бэкапе» — поправили историю. Restore всегда копированием в другой каталог, никогда правкой на месте.

Раскладка каталогов, с которой потом не стыдно жить

Я не нумерую snapshot.0 … snapshot.7, если нет rsnapshot. Номера крутятся mv, в панике в три ночи легко перепутать, что сейчас «сегодня». Даты читаются без расшифровки:

/backup/host-a/
    2026-08-25/
    2026-08-26/
    2026-08-27/
    latest -> 2026-08-27

Отдельный корневой каталог на хост. Не сваливать сайты разных машин в одну кучу: hardlink работает только внутри одной файловой системы, а путать, чей это wp-config.php, в аварии дорого.

Диск под бэкапы — отдельный раздел или отдельный диск. Не /var той же машины, которую снимаете. И не NFS, если рассчитываете на hardlink: на NFS hardlink либо запрещён, либо ведёт себя так, что экономии не получите, а du сойдёт с ума. --link-dest требует, чтобы каталог назначения и каталог link-dest были на одной ФС. Проверка перед первым запуском:

df -P /backup/host-a | awk 'NR==1 || {print $1, $6}'
stat -f -c '%i' /backup/host-a   # filesystem id, должен совпасть у всех слепков

Если снимаете несколько источников на один раздел — нормально. Если бэкап-диск собрали из двух mount — rsync молча начнёт копировать файлы вместо hardlink, место кончится через несколько ночей, в логе это будет не ошибкой.

Первый слепок и все следующие

Первый прогон — обычный полный rsync, без --link-dest. Каталога для ссылок ещё нет.

SRC=/var/www/site
ROOT=/backup/host-a
TODAY=$(date +%F)

mkdir -p "$ROOT/$TODAY"
rsync -aH --numeric-ids --delete --one-file-system \
  "$SRC/" "$ROOT/$TODAY/"
ln -sfn "$TODAY" "$ROOT/latest"

Следующие ночи — тот же приём, плюс ссылка на предыдущий слепок. Предыдущий я беру не из latest до обновления симлинка, а явно: последний каталог с датой, который не равен сегодняшнему. Если ночной прогон перезапустили дважды за сутки, второй раз должен писать в тот же $TODAY, а не плодить 2026-08-27-1.

SRC=/var/www/site
ROOT=/backup/host-a
TODAY=$(date +%F)
DEST="$ROOT/$TODAY"
PREV=$(find "$ROOT" -mindepth 1 -maxdepth 1 -type d -name '20*' \
        ! -path "$DEST" | sort | tail -n1)

mkdir -p "$DEST"
RSYNC_OPTS=(-aH --numeric-ids --delete --one-file-system --partial)

if [ -n "$PREV" ]; then
  rsync "${RSYNC_OPTS[@]}" --link-dest="$PREV" "$SRC/" "$DEST/"
else
  rsync "${RSYNC_OPTS[@]}" "$SRC/" "$DEST/"
fi

ln -sfn "$TODAY" "$ROOT/latest"

Слэш после $SRC/ обязателен: копируем содержимое, а не каталог «site» внутрь слепка. Без слэша через год получите /backup/host-a/2026-08-27/site/... вперемешку со старыми прогонами, где слэш уже стоял.

По флагам, без которых потом больно:

• -a — права, времена, симлинки, устройства. Без этого слепок «как файлы», не «как система».
• -H — сохранить hardlink в источнике. Это не про --link-dest. Если на проде два имени на один inode, без -H в бэкапе станут две копии.
• --numeric-ids — uid/gid цифрами, без подстановки имён. На бэкап-сервере пользователь www-data часто другой uid. Без флага права «починятся» молча и неправильно.
• --delete — в новом слепке нет того, чего уже нет на источнике. Старые слепки это не трогает.
• --one-file-system — не уехать в /mnt, bind-mount и чужой NFS, который примонтировали «на пять минут».

ACL и xattr на нормальном сайте часто не нужны. Если нужны — добавляю -AX, и проверяю, что приёмник их умеет. На копии «через промежуточный tar на FAT» они умрут, hardlink тут ни при чём.

Тянуть по SSH с другой машины — тот же набор, источник user@host-a:/var/www/site/. Ключ только для чтения нужных путей, не root с интерактивным шеллом «потому что так проще». Хостнеймы в скриптах и known_hosts — свои, не клиентские FQDN из тикета.

Что rsync считает «тем же файлом»

По умолчанию — размер и mtime. Совпали оба, содержимое не читает. Для дерева из сотен тысяч php/jpg это правильно: иначе каждую ночь будете гонять диск впустую.

Где это врёт:

• бэкап-скрипт или деплой делают touch по дереву — mtime новый, rsync решит, что всё изменилось, hardlink не состоится, слепок станет почти полным;
• наоборот: файл переписали, mtime оставили (редкость, но бывает у кривых копировщиков) — в слепке останется старое содержимое через hardlink;
• права/владелец поменялись, размер и mtime нет — с обычным -a rsync всё же обновит метаданные. С hardlink это тонкое место: смена владельца на inode видна во всех слепках, которые на него ссылаются. На практике для «сайт + загруженные картинки» почти не всплывает. На домашних каталогах с постоянным chown — всплывает.

--checksum лечит второй случай и наказывает диск. Я включаю его точечно, не «на всякий случай каждый день». Для проверки целого слепка после аварии — да. Для ночного прогона магазина с десятками гигабайт upload — нет.

Ещё одна мина: --inplace. Он пишет в существующий файл. Существующий файл в новом слепке после hardlink — это тот же inode, что вчера. --inplace вместе с --link-dest портит историю. Не включать.

Что не класть в слепок живьём

Rsync снимает файлы. Он не делает консистентный снимок СУБД и не понимает очереди почты.

MySQL/MariaDB: ночью mysqldump (или mariadb-dump) в файл, и в слепок идёт дамп, не /var/lib/mysql. Снимать datadir на работающем сервере — лотерея с битым InnoDB. Если очень нужен сырой datadir — только после FLUSH TABLES WITH READ LOCK / горячего снимка LVM/ZFS, и это уже другая схема, не «просто rsync».

PostgreSQL: pg_dump или pg_basebackup, не rsync по base/ на живой базе.

Сессии PHP, кэш, node_modules, очереди — либо exclude, либо смириться, что слепок на 80% состоит из мусора, который ещё и каждый раз «изменился». Типичный exclude для сайта:

/wp-content/cache/
/wp-content/uploads/cache/
/tmp/
/var/tmp/
*.log

Передаю через --exclude-from=/etc/backup/site.excludes. Не размазывать exclude по трём скриптам: через полгода никто не вспомнит, почему картинки из uploads вдруг не попали в слепок.

Полный бэкап системы — отдельный разговор. /proc, /sys, /dev, /run не снимают. --one-file-system как раз спасает от этого, если корневой слепок берёте с /. Загрузчик, UUID в fstab, криптозаголовки — rsync их «как файлы» скопирует, но загрузиться с такого каталога просто так нельзя. Для «откатить сайт» этого достаточно. Для «восстановить весь сервер» я не выдаю rsync-слепок за образ диска.

Место на диске: почему du врёт, если мерить по одному каталогу

Заходите в слепок — du -sh 2026-08-27 показывает почти полный размер сайта. Так и должно быть: внутри каталога почти все файлы «настоящие» с точки зрения дерева, просто inode общие с соседом. Смотреть надо сумму по корню и сравнение «по отдельности vs вместе»:

du -sh /backup/host-a
du -sh /backup/host-a/20*
du -sh --apparent-size /backup/host-a/20*

Первая строка — сколько занято уникальными данными. Список по датам — каждый слепок выглядит толстым. --apparent-size ближе к «логическому» объёму дерева. Если уникальный du по корню прыгает на размер всего сайта после очередной ночи — hardlink не сработал. Типичные причины: слепки на разных ФС, первый прогон без --link-dest в уже существующий каталог с другими inode, массовый touch, копирование через промежуточный диск без сохранения inode.

Иноды кончаются раньше байтов, если мелких файлов много. WordPress с кэшем и тучей php это умеет:

df -h /backup
df -i /backup

Если IUse% под 80%, а место ещё есть — либо чистить старые слепки, либо не снимать то, что exclude должен был отсечь.

Ротация у меня тупая и предсказуемая: хранить 7 дневных, плюс «первое число месяца», если место позволяет. Удалять целиком каталог даты, не файлы изнутри:

# всё старше 14 дней, кроме 01-го числа
find /backup/host-a -mindepth 1 -maxdepth 1 -type d -name '20*' \
  | sort | head -n -14 | while read -r d; do
      b=$(basename "$d")
      case $b in *-01) continue ;; esac
      rm -rf "$d"
    done

rm -rf по hardlink-дереву безопасен: уменьшает nlink, чужие слепки не трогает. Не делать chmod -R a-w по слепку «чтобы никто не правил». chmod пишет в inode. Общий inode — права поменяются и во вчерашнем слепке. «Защита от записи» — монтированием раздела ro на чтение, отдельным пользователем без записи, не chmod по живым hardlink.

Проверка restore: код 0 у rsync ничего не доказывает

Ночной прогон вернул 0. Это значит: rsync отработал. Это не значит, что из слепка поднимется сайт. Я отдельно гоняю проверку, хотя бы раз в неделю, на копию в песочницу, не на прод.

Минимум, который реально ловит беду:

SNAP=/backup/host-a/2026-08-27
TEST=/tmp/restore-test.$$
mkdir -p "$TEST"

# копируем, не линкуем: иначе снова общий inode
rsync -aH --numeric-ids "$SNAP/" "$TEST/"

# дерево не пустое, ключевые файлы на месте
test -s "$TEST/wp-config.php"
test -d "$TEST/wp-content/uploads"

# сравнение числа файлов — расхождение сразу видно
echo -n "snap:  "; find "$SNAP" -type f | wc -l
echo -n "copy:  "; find "$TEST" -type f | wc -l

# несколько случайных файлов — содержимое не нулевое и совпадает
find "$SNAP" -type f | shuf -n 20 | while read -r f; do
  rel=${f#"$SNAP"/}
  cmp -s "$SNAP/$rel" "$TEST/$rel" || echo "DIFF $rel"
done

Если это дамп базы — мало «файл не пустой». Нужен пробный импорт в отдельный экземпляр и SELECT COUNT(*) по жирной таблице, плюс открыть пару записей глазами. Дамп в 200 байт с ошибкой доступа тоже «файл на месте».

Если бэкап тянется по SSH — раз в неделю снимаю md5/sha256 списка ключевых файлов на источнике и в свежем слепке. Не всего дерева: достаточно конфигов, .env, пары известных загрузок. Расхождение mtime при том же содержимом меня не пугает. Расхождение содержимого — уже инцидент, даже если сайт «вроде открывается».

Что я ещё смотрю после ночного прогона, не дожидаясь недели:

• код выхода rsync и последние строки лога: rsync error, обрыв по SSH, vanished files пачкой;
• размер корня du -sh /backup/host-a относительно вчера — скачок на полный объём сайта;
• что симлинк latest указывает на сегодняшнюю дату, а не застрял на прошлой неделе;
• что в слепке нет пустого дерева из-за опечатки в источнике (rsync прекрасно синхронизирует пустой каталог и с --delete вычистит новый слепок подчистую, старые не трогая).

Пустой источник — отдельный класс аварии. Защита простая: если find "$SRC" -type f | wc -l меньше порога, скрипт выходит, не вызывая rsync. Порог свой для каждого дерева, не «больше нуля».

Типичные поломки, которые я уже не ищу по второму разу

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

Два слепка на разных ФС. --link-dest молча деградирует в полное копирование. Лечится только тем, что df смотрят до, а не после письма «диск кончился».

Запуск от пользователя, который не читает часть дерева. Rsync пропускает файлы с Permission denied и в конце может вернуть код 23. Часть людей глотает 23 как «ну почти ноль». Для бэкапа 23 — это дырка. Либо root на чтение, либо доступ по группе, либо явный список, и код 23 будит, а не пишется в лог «на всякий случай».

Живая база в слепке. Сайт после restore «открывается», заказы за вчерашние полдня разъехались. Dump рядом со слепком файлов, одной датой.

chmod/chown по слепкам. История переписана во всех датах, которые делили inode.

Один и тот же destination каждый раз, а –link-dest в соседнюю копию «для экономии». Если destination не чистый каталог новой даты, а вечно живой /backup/current, вы снова приехали к схеме «есть только сегодня». --link-dest имеет смысл, когда новый слепок — новый каталог.

Cron в локальной полночи и пик записи на сайте. Для файлового дерева это обычно терпимо: максимум файл середины заливки. Для заказов и почты — нет. Файлы ночью, дамп базы в окно минимальной нагрузки, не наоборот.

Когда этого достаточно, а когда уже нет

rsync --link-dest хорошо закрывает: сайт, домашние каталоги, конфиги, каталог загрузок, «хочу зайти и забрать вчерашний wp-content». Прозрачность тут важнее степени сжатия. Я могу отдать человеку путь и сказать: копируй отсюда. Без fuse, без restic mount, без сюрприза «репозиторий не открывается, ключ от другого хоста».

Плохо закрывает: много маленьких постоянно меняющихся файлов (тотальный выигрыш hardlink падает), нужна дедупликация между разными машинами, нужен шифрованный репозиторий на чужой площадке. Туда Borg/restic. Не вместо проверки restore — поверх другой модели хранения.

Обёртки вроде rsnapshot делают ровно это же, плюс ротацию hourly.0. Если ставит человек, который не хочет писать скрипт — пусть ставит. Если уже наступил на chmod и на NFS, лучше свой скрипт на два экрана: в нём видно, куда смотреть, когда слепок внезапно стал полным по диску.

И последнее, без чего схему не считаю рабочей: хотя бы один успешный restore в отдельный каталог, с поднятым экземпляром или хотя бы с проверенным дампом. Пока этого не было, у вас не бэкап, а ночной rsync с красивыми датами на каталогах.

На виртуалке load врёт чаще, чем на железе. Он не отделяет «мои процессы жрут CPU» от «диск лёг» и от «гипервизор забрал кванты времени у соседа». Если не разложить эти три штуки, будете лечить не того.

Что на самом деле считает load average

Load — это не «загрузка процессора в процентах». Это средняя длина очереди: сколько задач либо готовы бежать на CPU, либо спят в uninterruptible sleep (состояние D, обычно ожидание диска или NFS).

Поэтому картина «load 12 при 70% idle» на двух ядрах — нормальная, если в D висит десяток php-fpm, а диск отвечает по 80–200 мс. Процессор свободен, очередь растёт. С steal time та же история: задача хочет CPU, гипервизор её не планирует, очередь тоже растёт, а в top вы видите idle плюс st.

Смотрю сразу три числа: load за 1/5/15 минут и сколько ядер (nproc). Load 4 на четырёх ядрах — ещё можно жить. Load 4 на одном vCPU уже несколько минут — уже инцидент. Пятнадцатиминутный load запаздывает: если тормоза начались три минуты назад, ориентируйтесь на единицу и на живые счётчики, не на «среднее за четверть часа».

Три столбца в top, без которых диагностика — гадание

В шапке top (клавиша 1 включает разбивку по ядрам) мне важна строка CPU:

%Cpu(s):  8.4 us,  3.1 sy,  0.0 ni, 41.0 id, 27.2 wa,  0.0 hi,  1.1 si, 19.2 st

Коротко по делу:

• us + sy — ваши процессы реально крутят код. Вот это «нехватка CPU у приложения».
• id — простой. Высокий idle сам по себе ничего не лечит и ничего не доказывает.
• wa — iowait: процессор свободен, но есть незавершённый I/O. Это не «диск загрузил CPU», это ожидание.
• st — steal: гипервизор отдал эти тики не вам. Ваша виртуалка хотела считать — ей не дали.
• si — softirq. Если внезапно большой на фоне сети, смотрю пакеты и netfilter, а не PHP.

Правило, которым я пользуюсь в первые 30 секунд: если us+sy низкие, а load высокий — это не «надо больше ядер приложению». Это либо диск, либо гипервизор, либо cgroup-троттлинг, который в st может вообще не попасть.

Steal time: когда виноват не ваш код, а сосед по ноде

Steal — доля времени, когда vCPU был готов работать, но гипервизор забрал слот. На нормально выделенном KVM с гарантией CPU st обычно около нуля, редкие всплески на 1–2% можно не драматизировать. На дешёвых VPS вечером я регулярно вижу 10–30% steal пачками по несколько минут. Формально у вас «2 ядра», фактически в этот момент — полтора или меньше.

Как это ощущается снаружи: сайт отвечает рывками, CPU в панели хостера «зелёный», процессы в top не жрут по 100%, латентность прыгает без изменения трафика. Внутри в это же время растёт очередь PHP/очередь диска — не потому что MySQL внезапно стал писать в десять раз больше, а потому что кванты CPU приходят дыряво.

Подтверждаю не одним кадром top, а рядом:

nproc
uptime
mpstat -P ALL 1 30
vmstat 1 30

В mpstat смотрю столбец %steal по каждому vCPU. Если steal сидит на всех ядрах стабильно выше примерно 5–8% и при этом %usr/%sys не упёрлись в потолок — это не ваше приложение «уперлось в CPU». Это нода. Если steal скачет нуль–сорок нуль–сорок синхронно на всех vCPU — классика оверселла, «шумный сосед» или ночной бэкап гипервизора.

В vmstat те же буквы в последнем столбце st, плюс r (run queue) и b (blocked on IO). Высокий r при низком us и ненулевом st — задачи ждут планировщика, а не вашего кода.

Важный нюанс: на части облаков CPU режут не через steal, а через кредиты/квоты. Тогда st может быть нулевым, а приложение всё равно ползёт. Это уже следующий раздел, не путайте с «честным» KVM-steal.

Iowait: load большой, процессор скучает, диск не отвечает

Вторая частая ловушка. Load 10, idle 60%, wa 30–40%. В ps куча процессов в D. Человек видит load и думает «CPU». Нет: очередь — на I/O.

ps -eo pid,user,state,wchan:24,etime,cmd | awk 'NR==1 || $3 ~ /D/'
iostat -xz 1 20
vmstat 1 20

В iostat мне важны не «красивые» MB/s, а await, aqu-sz и %util. Если на vda/vdb await уехал в десятки–сотни миллисекунд при скромном объёме записи — это не «MySQL плохо настроен», это сторадж ноды. На дешёвом VPS диск почти всегда общий. Сосед запустил бэкап — ваш InnoDB начинает ждать fsync.

Отдельно проверяю swap:

free -h
vmstat 1 10

Ненулевые si/so в vmstat плюс высокий iowait — это уже не «мало CPU», это память кончилась и система молотит страницы. Добавление ядер тут бесполезно. И увеличение pm.max_children в такой ситуации обычно делает хуже: больше процессов — больше давления на диск и RAM.

NFS, CIFS, зависший iSCSI дают ту же картину: D-state, растущий load, CPU почти idle. wchan в ps часто прямо намекает (io_schedule, nfs, wait_on_page). Не лечите это рестартом php-fpm, пока не поняли, на чём они спят.

Реальная нагрузка: когда процессы правда жрут CPU

Это самый скучный и самый честный случай. us+sy под 80–100% на всех ядрах, steal около нуля, iowait низкий, в top по CPU видны конкретные pid: php-fpm, mysqld, node, python. Load примерно согласован с числом ядер и run queue.

Тогда уже имеет смысл:

pidstat -u 1 10
ps -eo pid,user,pcpu,pmem,cmd --sort=-pcpu | head
# если есть perf и можно ненадолго:
# perf top -g

Искать медленный запрос, воркера без лимита, cron, который внезапно переложил всю таблицу. Здесь апгрейд CPU поможет. На steal и на дохлый диск — нет, вы просто будете дороже ждать то же самое.

Не путайте короткий всплеск (деплой, прогрев кэша, один тяжёлый отчёт) с системной нехваткой. Смотрите 5-минутное окно, не один кадр.

Четвёртая ловушка: cgroup throttle без steal

На контейнерах (LXC, часть «VPS из панели», Kubernetes) CPU часто режут квотой cgroup, а не классическим steal. В top тогда st=0, idle может быть приличным, а латентность всё равно плохая: вас просто не пускают на CPU сверх квоты.

На cgroup v2:

cat /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max
cat /proc/pressure/cpu

В cpu.stat смотрю nr_throttled и throttled_usec. Если throttled растёт на глазах — вас режут. cpu.max вида 20000 100000 на двух видимых vCPU означает, что «два ядра» в nproc — картинка, а лимит другой.

PSI (/proc/pressure/cpu и io) удобен тем, что показывает stall some/full за 10/60/300 секунд. full по CPU — никто не мог работать. Это ближе к правде, чем load, когда хочется понять «прямо сейчас нас душили или пять минут назад».

На старых OpenVZ/Virtuozzo картина ещё мутнее: иногда steal есть, иногда только failcnt в beancounters. Если попали на такое — не делайте выводы по одному top, смотрите лимиты панели и cpu.stat.

Порядок, которым я отличаю гипервизор от реальной нагрузки

Не распухающий чеклист, а последовательность на пять минут.

1. Снять размер машины и load: nproc, uptime, free -h. Понять, не swap ли это вообще.
2. Живой top, клавиша 1. Записать us/sy/id/wa/st. Не скриншот «процессы», а шапку CPU.
3. mpstat -P ALL 1 30 и vmstat 1 30 — steal стабильный или вспышками, run queue, blocked.
4. Если wa заметный — iostat -xz 1 20 и список D-процессов с wchan.
5. Если st≈0 и CPU не упирается — cpu.stat / cpu.max / /proc/pressure/cpu.
6. Только если us+sy высокие и лимиты не душат — иду в pidstat и уже в приложение.

За эти пять минут обычно ясно, в какую из четырёх корзин класть инцидент. Дальше уже либо тикет хостеру с цифрами, либо диск, либо квота, либо профилирование PHP/SQL.

Что не делать, пока не поставили диагноз

Не поднимать pm.max_children «чтобы очередь рассосалась». На iowait и на steal это увеличивает очередь, а не уменьшает.

Не добавлять swap «для запаса», если si/so уже ненулевые. Вы лечите нехватку RAM ещё большим iowait.

Не рестартить MySQL по кругу, если await диска сотни миллисекунд. Рестарт в этот момент — лотерея с порчей и долгим recovery.

Не просить «ещё два ядра» у хостера, имея на руках только load average. Load на оверсолде растёт и от steal, и от диска. Без mpstat/iostat вам продадут тот же оверсолл подороже — или, что чаще, просто перекинут на такую же ноду.

Как разговаривать с хостером, чтобы это не было «сайт тормозит»

Тикет без цифр на оверсолде заканчивается шаблоном «на ноде всё хорошо, смотрите приложение». Я прикладываю 30 секунд mpstat -P ALL, кусок vmstat, если надо — iostat, время (UTC), и формулировку в духе: «на 2 vCPU стабильно %steal 15–25 при %usr+%sys < 30, load растёт, iowait такой-то. Прошу проверить contention на ноде / переезд». Не имена клиентов, не внутренние IP, не «у нас прод упал».

Если хостер нормальный, на устойчивом steal они переезжают. Если нет — имеет смысл менять площадку, а не тюнить opcache. Оптимизация приложения на 10% не лечит потерю четверти CPU каждую минуту.

Для себя оставляю те же логи локально на время разбора. Через час steal может исчезнуть, и вы останетесь с «ну у нас сейчас всё зелёное».

Коротко: как не перепутать корзины

Реальная нагрузка: us+sy высокие, st≈0, wa низкий, в top видны конкретные процессы. Лечите код, запросы, лишние воркеры. Ядра помогут.

Нехватка CPU у гипервизора: st стабильно заметный, us+sy не упираются, load и латентность прыгают без роста трафика. Лечите площадку, не php.ini.

Диск: wa высокий, процессы в D, await большой. Часто на тех же дешёвых VPS соседствует со steal — нода оверsold и по CPU, и по стораджу. Сначала цифры, потом выводы.

Квота cgroup: st=0, cpu.stat throttled растёт, PSI full по CPU. «Два ядра» в панели ≠ два ядра в планировщике.

Пока эти четыре строки не разложены, любой совет «увеличьте лимиты PHP» — гадание. Снимается это стандартными утилитами за несколько минут, без агентов и без панелей. Панель хостера в этот момент почти всегда врёт в оптимистичную сторону: она рисует «выданные» ядра, а не те, которые вам реально отдали.

Проверяем, авторизован ли пользователь на сервере, и есть ли запущенные от него процессы

who
sudo ps -u username

Убиваем процессы пользователя, если они есть

sudo killall -9 -u username

Отключаем все задачи планировщика cron этого пользователя

sudo crontab -r -u username

Собственно удаляем пользователя

Если нужно удалить пользователя, но оставить его домашнюю директорию, то выполняем:

sudo deluser username

Если нужно удалить всё, включая и его домашнюю директорию, то выполняем команду:

sudo deluser --remove-home username

Команда grep

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

grep "ключевое_слово" /путь/к/файлу.txt

Для рекурсивного поиска в каталогах вы можете использовать опцию -r, позволяющую искать вложенные файлы и подкаталоги. Пример:

grep -r "искомый_текст" /путь/к/каталогу

find и xargs совместно

Комбинация команд find и xargs позволяет находить файлы с заданными критериями и передавать их в качестве аргументов для других команд. Пример:

find /путь -type f -exec grep "искомый_текст" {} +

В данном примере find находит все файлы (-type f) в указанном пути и передает их в grep, где производится поиск заданного текста.

find и grep совместно

Комбинирование find и grep позволяет более тонко настраивать поиск. Например, поиск в файлах, измененных за последние 7 дней:

find /путь -type f -mtime -7 -exec grep "искомый_текст" {} +

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

Что такое cron?

Cron — это стандартный инструмент в Unix-подобных системах, предназначенный для выполнения задач в установленное время или периодически. Он основан на файлах cron, в которых определены задания и их расписание. Эти файлы хранятся в каталоге /etc/cron.d/ или /var/spool/cron/ и обычно недоступны для редактирования напрямую.

Работа с cron

Создание и редактирование cron-задач

Для создания новой задачи, или редактирования существующих, используется команда:

crontab -e

Она открывает текстовый редактор, в котором можно определить расписание и команду для выполнения. Например, чтобы запустить скрипт “myscript.sh” каждый день в 2 часа ночи, добавьте следующую строку:

0 2 * * * /путь/к/скрипту/myscript.sh

Редактировать команды другого пользователя можно так:

sudo crontab -u username -e

Листинг задач

Список текущих cron-задач можно просмотреть с помощью команды:

crontab -l

Это полезно для проверки текущего расписания и быстрого определения того, что уже настроено.

Вывести задачи другого пользователя можно так:

sudo crontab -u username -l

Удаление задач

Эта команда удаляет все cron-задачи пользователя:

crontab -r

Если необходимо удалить конкретную задачу, используйте:

crontab -l

чтобы увидеть ее номер, а затем:

crontab -r номер

Вывод результата в лог-файл

Для записи результатов выполнения задачи в лог-файл, вы можете использовать перенаправление стандартного вывода и стандартной ошибки в файл прямо внутри команды cron. Вот пример:

* * * * * /путь/к/вашему/скрипту.sh >> /путь/к/лог-файлу.log 2>&1

Здесь >> используется для добавления вывода в конец файла, 2>&1 перенаправляет стандартные ошибки в стандартный вывод, чтобы они также попадали в лог-файл.

Указание времени выполнения задач

В планировщике задач cron в Linux время выполнения задач задается в виде пяти полей, каждый из которых представляет собой определенный аспект времени. Эти поля определяют минуты, часы, дни месяца, месяцы и дни недели. Вот структура этих полей:

* * * * *
- - - - -
| | | | |
| | | | +----- День недели (0 - воскресенье, 1 - понедельник, ..., 6 - суббота)
| | | +------- Месяц (1 - январь, 2 - февраль, ..., 12 - декабрь)
| | +--------- День месяца (1 - 31)
| +----------- Час (0 - 23)
+------------- Минуты (0 - 59)

Каждое поле может принимать определенные значения или диапазоны значений, а также знаки “*” (звездочка) и “/” (косая черта).

• *: Означает “каждый”. Например, если в поле минут стоит “*”, это означает, что задача будет выполняться каждую минуту.
• число: Определенное значение. Например, если в поле часов стоит “3”, задача будет выполняться в 3 часа.
• число-число: Диапазон значений. Например, “1-5” в поле дней недели означает с понедельника по пятницу.
• */число: Каждый определенный интервал. Например, “*/15” в поле минут означает каждые 15 минут.

Примеры:

Запуск задачи каждый день в 3 часа утра:

0 3 * * *

Запуск задачи каждый понедельник и среду в 12:30:

30 12 * * 1,3

Запуск задачи каждый час:

0 * * * *

Запуск задачи каждый день в 5 утра и 8 вечера:

0 5,20 * * *

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

Поиск больших файлов с сортировкой по убыванию, с выводом в терминал только 20 больших файлов,  в указанной папке

find /путь/к/каталогу -type f -size +100M -exec du -h {} + | sort -rh | head -n 20

Эта команда ищет файлы размером более 100 мегабайт в указанном каталоге и его подкаталогах, затем сортирует результаты по размеру в убывающем порядке.

Поиск больших файлов с сортировкой по убыванию в текущей папке

find . -type f -size +500M -exec du -h {} + | sort -rh

Эта команда ищет файлы размером более 500 мегабайт в текущем каталоге и его подкаталогах, затем сортирует результаты по размеру в убывающем порядке.

Поиск больших папок с сортировкой по убыванию и выводом в терминал только 20 самых больших папок

du -h --max-depth=1 /путь/к/каталогу | sort -rh | head -n 20

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

Поиск папок, содержащих большое количество файлов, с сортировкой по убыванию, и выводом только 20 таких папок

find /путь/к/каталогу -type d -exec sh -c 'echo -n "{} " && find "{}" -maxdepth 1 -type f | wc -l' \; | sort -k2 -nr | head -n 20

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

Для проброса приватного ключа используется SSH Агент. Способ одинаково работает в консоли любых операционных систем Linux, macOS и Windows.

Первым делом проверяем, запущен ли агент, и знает ли он что-то о вашем ключе:

ssh-add -l

Если получаем ответ: Could not open a connection to your authentication agent, запускаем агент командой:

eval 'ssh-agent'

Если ответ: The agent has no identities, значит нужно сообщить ему о вашем приватном ключе, выполнив команду:

ssh-add

Если в ответе команды ssh-add -l вы видите путь к своему приватному ключу, значит всё хорошо, и вы можете подключаться к удалённому серверу по ssh, добавив при подключении опцию -A, то есть вот так:

ssh -A user@host:port

Или можно установить опцию ForwardAgent yes в файле ~/.ssh/config на вашем локальном компьютере:

Host *
  ForwardAgent yes

Для проверки, что всё хорошо и ключ проброшен, на удалённом сервере можно выполнить команду:

echo "$SSH_AUTH_SOCK"

Если всё ок, то она должна вернуть что-то похожее на:

/tmp/ssh-DCIux21917/agent.21917