--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 с красивыми датами на каталогах.

Типичная болячка платформы Zafira A / Astra G: в резиновой гофре между стойкой кузова и торцом двери переламывается жгут. Симптомы обычно по одной двери:

• стеклоподъёмник то работает, то нет;
• не отрабатывает ЦЗ этой двери;
• пропал или хрипит звук из этой двери (провода динамика идут тем же жгутом);
• на приборке нет индикации открытой двери.

Менять замок, мотор стеклоподъёмника и сам динамик чаще всего рано. Дверь изнутри разбирать не нужно: жгут от двери отстёгивается разъёмом на торце, а ремонтируется та часть проводки, которая уходит в кузов через гофру (стойка / порог).

Левая и правая — разные жгуты и разная распиновка. Чините правую — не копируйте цвета с левой.

Почему ломается

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

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

Что нужно

• мультиметр;
• пайка или медные гильзы + термоусадка;
• мягкий провод (силикон / фторопласт): сигнальные ~0.5–0.75 мм², силовые стеклоподъёмника заметно толще;
• по желанию — более мягкая гофра и смазка, чтобы при закрытии двери провода уходили в стойку, а не ломались в перегибе.

Минус АКБ снять сразу: толстый красный на мотор стекла часто под постоянным плюсом.

Как добраться до жгута (дверь не разбираем)

Всё делается снаружи торца двери и из салона у стойки.

1. Открыть заднюю дверь. На переднем нижнем торце — многоконтактная колодка, вокруг неё стопорное кольцо (часто синее).
2. Нажать/сжать кольцо и вытянуть разъём из двери. Дверь остаётся в сборе: обшивку, динамик, замок не трогаем.
3. Снять пластиковое кольцо/фиксатор, которым гофра держится на колодке.
4. Со стороны кузова освободить гофру из отверстия в стойке. При необходимости снять накладку порога / низ облицовки стойки — так жгут удобнее вытянуть в салон.
5. Вытянуть в салон именно кузовную часть жгута вместе с гофрой и осмотреть жилы. Удобный приём: после снятия разъёма слегка прикрыть заднюю дверь и работать из проёма передней — жгут подаётся вперёд, к обрывам проще подобраться.

Оборванный провод часто находится натяжением: целые держат, оборванный выезжает отдельно. Типичное место — зона постоянного перегиба в гофре.

До резки: фото колодки и маркировка каждого провода. Левый и правый жгуты потом легко перепутать.

Чем левая дверь отличается от правой

• на разборке жгуты идут отдельно «задняя левая» / «задняя правая»;
• свои цепи: мотор стекла, активатор ЦЗ, концевик, динамик — у сторон разные;
• расцветка тонких жил (особенно акустика и управление стеклом с водительского пульта) слева и справа не обязана совпадать — «по аналогии с другой дверью» как раз и ошибаются;
• общее у обеих: толстый красный (+) и толстый коричневый (масса) мотора стеклоподъёмника — силовая пара, её ломает чаще всего.

Типовая распиновка разъёма (ориентир)

Это колодка на стыке «дверь жгут в кузов». Ниже — рабочий ориентир по ролям контактов (LHD, типовая комплектация). Пустые номера — резерв/опции. Точные цвета тонких жил сверяйте на своей стороне двери.

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

Как ремонтировать

1. Вырезать повреждённый участок на кузовной стороне жгута (в зоне гофры / входа в стойку).
2. Вставить мягкий провод с запасом длины, чтобы жгут мог уходить в стойку при закрытии двери, а не стоять внатяг.
3. Стыки (пайка + термоусадка или обжим) вынести из зоны постоянного перегиба — внутрь стойки/порога, не оставлять «шишку» посередине гофры.
4. Собрать гофру, воткнуть разъём обратно в торец двери, проверить на этой двери: стекло, ЦЗ, звук, концевик.

Чтобы гофра снова не убила жгут: чуть смазки на провода и/или более мягкая гофра — при закрытии двери жилы должны ускользать в кузов, а гофра сжиматься сама.

Готовые ремкомплекты с маркетплейсов

Можно не нарезать провода вручную: на маркетплейсах продают готовые ремкомплекты жгута задней двери (мягкая проводка + разъём/пины под штатную колодку). У Опелей они с виду похожи, но не взаимозаменяемые вслепую.

• отличаются по поколению (Zafira A ≠ Zafira B, ловите дорест/рест);
• отдельно под левую и под правую заднюю дверь;
• сверьте фото разъёма и комплектацию в карточке со своей колодкой до заказа.

Берите ремкомплект именно под свою машину и именно под ту дверь, которую чините.

Итого: дверь не разбираем. Отщёлкнули разъём на торце, вытянули кузовную часть жгута из стойки, нарастили/поменяли участок в зоне гофры, собрали обратно. Левая и правая — разные жгуты; цвета с «другой стороны» не копировать.

На виртуалке 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» — гадание. Снимается это стандартными утилитами за несколько минут, без агентов и без панелей. Панель хостера в этот момент почти всегда врёт в оптимистичную сторону: она рисует «выданные» ядра, а не те, которые вам реально отдали.

Зато разъём под это реле у большинства машин уже есть. И из обычного автомобильного реле за копейки получается очень вменяемый самодельный модуль: завели мотор — загорелся ближний (и при желании габариты с приборкой), заглушили — всё погасло, штатная крутилка света продолжает работать как надо.

Где искать разъём

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

Ищите чёрную пластиковую колодку на 8 контактов. Обычно она плотно примотана к жгуту изолентой — из‑за этого многие думают, что разъёма нет, хотя на деле это просто «аппендикс» на косе. Увидел подозрительное утолщение с нужными цветами проводов — смело разрезайте изоленту.

Важный момент: на самых ранних машинах (типа 1999 года) и в базовых южных комплектациях разъёма могло не быть — у Опелей тех лет была лотерея с проводкой. Шанс найти его большой, но не стопроцентный. Если колодки нет — ту же схему можно собрать, врезаясь к проводам у переключателя света и замка зажигания, но это уже менее аккуратно.

Распиновка штатной колодки (реле K59)

Цвета — европейские, по DIN. Даже если цифры на пластике стёрлись, по проводу всё равно ориентируешься.

Белый (пин 8) в заводском блоке нужен для хитрой логики: при «моргании» дальним на долю секунды гасить ближний. На обычном реле JD1912 это гнездо просто оставляем пустым — штатный дальний от этого не ломается.

Чёрный и жёлтый заметно толще остальных — силовые. На контакты 30 и 87 реле берите провод не тоньше 1.5 мм², иначе будет греться.

Простое решение: обычное реле JD1912

Можно взять спецреле времени вроде «Регтайм‑3» и получить задержку в пару секунд после старта. Но если честно — для машины это скорее приятность, а не необходимость, да и выходит заметно дороже.

Сине‑белый провод (D+) сам по себе даёт нужную логику:

• зажигание включили — на нём 0 В;
• крутите стартер — тоже 0 В, фары не жрут аккумулятор;
• мотор завелся, генератор пошёл в плюс — на проводе +12/+14 В, реле щёлкнуло, свет загорелся;
• заглушили — питание пропало, свет погас.

Реле JD1912 (12В, 30–40А) для этой задачи подходит идеально. Две лампы ближнего + габариты + приборка тянут примерно 12–15 А, запас по току нормальный. На донышке те же контакты 30 / 85 / 86 / 87 — ничего изобретать не надо. К реле сразу берите пластиковую колодку («фишку» с проводами) — копейки, а жить с ней сильно приятнее.

По сути нужен минимальный набор из автомагазина и радиодеталей:

• обычное 4‑контактное реле 12В (JD1912 или любое ВАЗ/ГАЗ);
• колодка под реле;
• диоды 10A10 или 6A10 — три штуки, если цепляете габариты и приборку;
• клеммы «папа» 6.3 мм — шесть штук.

Всё это сущие копейки, а модуль втыкается в штатный разъём без резки родной проводки.

Самый простой вариант: только ближний

Если подать питание с реле только на жёлтый провод (пин 4), загорятся исключительно фары ближнего. Ни задние фонари, ни мелкие передние габариты, ни номер, ни приборка — ничего. В Опеле цепи ближнего и габаритов физически разделены.

И это даже удобно как дневные ходовые:

• схема из четырёх проводов, без диодов, собирается за десять минут;
• днём сзади ничего лишнего не горит, лампочки в задних фонарях и подсветке номера отдыхают;
• вечером или в тоннеле привычка одна: повернул штатную крутилку. Тёмная приборка как раз подсказывает, что забыли.

Подключение:

• пин 1 (коричневый) → контакт 85 реле (масса);
• пин 3 (сине‑белый) → контакт 86 (управление от генератора);
• пин 5 (чёрный) → контакт 30 (+12В от зажигания);
• контакт 87 → пин 4 (жёлтый, ближний).

Вариант «по‑человечески»: ближний + габариты + приборка

Если хочется, чтобы при заведённом моторе горело всё «по кругу», от контакта 87 реле делаем разветвление:

• напрямую на пин 4 (жёлтый) — ближний;
• через диод (полоской от реле) на пин 6 — левые габариты;
• через диод на пин 7 — правые габариты;
• через диод на пин 2 — подсветка приборки и номера.

Диоды обязательны. Без них:

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

Диод тут как ниппель: пускает ток от вашего реле к лампам и не пускает обратно в штатную схему.

Кстати, заводское опелевское реле приборку специально не включает. Логика безопасности: заехали в тёмный тоннель — тёмная панель намекает, что у вас только дневной режим, пора включить нормальный свет. Если вам днём комфортнее с подсвеченной приборкой — третий диод на пин 2, штатной проводке это не вредит.

Как себя ведёт крутилка света вместе с самоделкой

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

Положение 0. Горят ближний, габариты (если вы их завели через диоды), приборка/номер. Дальний можно только «моргнуть». ПТФ не включить.

Положение 1 (габариты). Визуально почти ничего не меняется. Появляются передние ПТФ (если есть). Постоянный дальний всё ещё не фиксируется.

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

Заглушили мотор — ваше реле обесточилось, крутилка снова главная:

• стояла на 0 — машина погасла;
• стояла на 1 — ближний погас, габариты остались (парковка);
• стояла на 2 — ближний погас, габариты горят, при открытии двери запищит напоминалка.

И да: когда включаете дальний штатно, ближний и габариты продолжают гореть. В фарах Zafira A ближний и дальний — разные лампы в разных секциях, не одна H4 с двумя нитями. Самоделка эту логику не ломает.

Сборка

Собираете «паука» на клеммах «папа» 6.3 мм, проверяете мультиметром, заливаете термоклеем / стягиваете изолентой / прячете в маленький корпус — и вставляете в штатную колодку. Родную проводку резать не нужно.

Если принципиально хочется именно задержку в пару секунд после старта — не обязательно брать дорогое автореле времени. На маркетплейсах полно недорогих плат «модуль задержки включения 12V на NE555», с крутилкой примерно на 0–10 секунд и уже встроенным реле. Логика проводов та же.

Получается просто, дёшево и по смыслу очень близко к тому, что задумал завод — только без поисков мифического оригинального блока по разборкам.

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

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

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

Что это за плагин?.

Elementor Pro – это популярный плагин для WordPress, который позволяет создавать профессионально выглядящие страницы и посты на сайте под управлением WordPress без необходимости знания кодирования.

Он предоставляет мощный визуальный редактор, который позволяет вам создавать страницы методом drag-and-drop (перетаскивания элементов), выбирать из более чем 80 встроенных виджетов (включая текстовые блоки, кнопки, формы и графики), а также импортировать готовые шаблоны, которые могут быть адаптированы под ваши нужды.

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

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

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

Эксплуатация уязвимости Elementor Pro

В настоящий момент наблюдаются массовые взломы сайтов на WordPress, использующих одновременно плагины WooCommerce и Elementor Pro версии ниже 3.11.7.

После взлома на сервере можно обнаружить новые файлы wp-resortpark.zip, wp-rate.php или lll.zip, однако естественно, могут быть файлы и с другими именами.

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

Плагин используется на 12 миллионах сайтов, из-за чего компания NinTechNet, сообщившая об уязвимости, присвоила рейтинг серьезности уязвимости 8,8 из 10.

Как защитить свой сайт на WordPress

Необходимо обновить плагин Elementor Pro до версии не ниже 3.11.7 (на момент написания этой статьи, актуальная версия 3.12.1). Хочу заметить, что плагин является платным.

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

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