Резервное копирование Linux-сервера через rsync с сохранением прав и атрибутов!

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

Базовый вариант синхронизации:

rsync -av /data/ /backup/data/

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

rsync -aHAX /srv/ /backup/srv/

Ключ -a сохраняет структуру каталогов, права, владельцев, группы, время изменения и символические ссылки. -H сохраняет жёсткие ссылки, -A переносит ACL, а -X сохраняет расширенные атрибуты.

При переносе между серверами важно сохранить исходные UID и GID, чтобы права доступа остались корректными:

rsync -aHAX --numeric-ids -e ssh /srv/ backup@10.0.0.20:/backup/server/

Для зеркального копирования используют параметр --delete. Он удаляет в резервной копии файлы, которых больше нет в источнике, поэтому перед применением стоит проверить изменения:

rsync -aHAX --delete --dry-run --itemize-changes /srv/ /backup/srv/

rsync часто применяется для миграции серверов и переноса больших объёмов данных через SSH:

rsync -aHAX -e ssh /srv/ backup@server:/backup/

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

rsync -aHAX --bwlimit=50M /srv/ backup@server:/backup/

При передаче больших файлов после разрыва соединения можно сохранить частично переданные данные:

rsync -aHAX --partial --progress /images/ backup@server:/backup/images/

Параметр --append-verify следует использовать осторожно. Он подходит для случаев, когда файл только дописывается и не изменяется в уже записанной части.

Для создания нескольких ежедневных копий часто используют --link-dest. Неизменившиеся файлы будут представлены жёсткими ссылками и не займут дополнительное место:

rsync -aHAX --link-dest=/backup/latest /data/ /backup/$(date +%F)/

Пример структуры хранения:

/backup/
├── 2026-08-13/
├── 2026-08-14/
├── 2026-08-15/
└── latest -> 2026-08-15/

После создания новой копии ссылку latest обычно обновляют на последний каталог.

При резервном копировании всей системы обычно исключают виртуальные файловые системы Linux:

rsync -aHAX \
--exclude=/proc \
--exclude=/sys \
--exclude=/dev \
--exclude=/run \
/ /backup/system/

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

Автоматический запуск можно настроить через cron:

0 3 * * * /usr/bin/rsync -aHAX --delete --log-file=/var/log/rsync-backup.log /srv/ /backup/srv/

Проверить различия между источником и копией без изменения данных можно через --dry-run:

rsync -aHAX --dry-run /srv/ /backup/srv/

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

rsync -aHAX --checksum --dry-run /srv/ /backup/srv/

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

rsync хорошо подходит для миграции серверов, синхронизации каталогов и создания файловых резервных копий. Однако это инструмент синхронизации, а не полноценная backup-система.

🔥 Он не гарантирует согласованное состояние работающих баз данных. Для MySQL, PostgreSQL и других сервисов обычно используют дампы, snapshots файловой системы или предварительную остановку приложения перед копированием. Надёжность резервной копии определяется не фактом её создания, а успешным восстановлением из неё.

🚪 Linux Ready | #практика

Знали, что отдельной команде можно выдать собственные /tmp и /var/tmp, не создавая контейнер?

Для этого у systemd есть свойство PrivateTmp:

systemd-run --user --pipe \
  -p PrivateTmp=yes \
  bash

Запущенная оболочка получает отдельные временные каталоги. Файлы, созданные программой в /tmp и /var/tmp, не будут видны через обычные /tmp и /var/tmp хоста.

Это удобно при запуске сборок, тестов и сторонних инструментов, которые создают множество временных файлов:

systemd-run --user --pipe \
  -p PrivateTmp=yes \
  npm test

После завершения временного unit systemd освобождает связанное с ним приватное пространство временных файлов.

При этом это не полноценная песочница: PrivateTmp=yes изолирует именно /tmp и /var/tmp, а остальные доступные программе пути сам по себе не скрывает.

🔥 PrivateTmp позволяет одной командой изолировать временные файлы конкретной задачи без Docker и ручного создания mount namespace.

🚪 Linux Ready | #совет

😍 Крайне интересная статья лежит на Хабре: «Как ядро Linux решает, какой процесс „убить“ при нехватке памяти»!

В этой статье:
• Разбирается работа OOM Killer: почему Linux допускает overcommit памяти и по каким метрикам выбирает процесс для завершения;
• Показывается, как диагностировать OOM через oom_score, oom_score_adj, логи ядра, cgroups и PSI;
• Рассматриваются способы защитить критичные сервисы и заранее реагировать на нехватку памяти с помощью systemd, earlyoom, nohang и systemd-oomd.


🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья

Работаем с SSH-конфигурацией: избавляемся от длинных команд подключения!

Если приходится регулярно подключаться к нескольким серверам, использовать разные SSH-ключи, нестандартные порты или подключаться через промежуточный сервер, длинные команды ssh быстро становятся неудобными. Для этого существует пользовательский файл конфигурации ~/.ssh/config, который позволяет хранить все параметры подключения в одном месте.

Если каталог ~/.ssh еще не существует, сначала создайте его и установите правильные права доступа:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

После этого SSH-клиент будет автоматически читать файл ~/.ssh/config при каждом подключении. Достаточно один раз описать нужные серверы, и в дальнейшем подключение станет значительно проще.

Например, добавим конфигурацию для рабочего сервера:

Host prod
    HostName 192.168.1.10
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Теперь вместо длинной команды:

ssh -i ~/.ssh/id_ed25519 deploy@192.168.1.10

достаточно выполнить:

ssh prod

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

Точно так же можно сохранить параметры подключения к серверу с нестандартным SSH-портом:

Host backup
    HostName backup.example.com
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_backup

После этого для подключения не нужно помнить номер порта или каждый раз использовать параметр -p:

ssh backup

Еще одна полезная возможность — использовать отдельные SSH-ключи для разных сервисов. Например, для GitHub:

Host github.com
    User git
    IdentityFile ~/.ssh/github
    IdentitiesOnly yes

Параметр IdentitiesOnly yes заставляет SSH использовать только ключи, явно указанные в конфигурации для этого подключения, а не автоматически перебирать все ключи, загруженные в SSH-агент. Это особенно полезно, если на компьютере используется несколько ключей для разных проектов или организаций.

Если нужный сервер доступен только через промежуточный сервер (bastion или jump-хост), это тоже легко настраивается:

Host internal
    HostName 10.10.0.15
    User admin
    ProxyJump bastion

Host bastion
    HostName bastion.example.com
    User jump

После этого достаточно выполнить всего одну команду:

ssh internal

SSH самостоятельно подключится к bastion-хосту, а затем автоматически перенаправит соединение на внутренний сервер. Никаких дополнительных действий выполнять не потребуется.

Чтобы SSH быстрее обнаруживал потерю соединения и не оставлял зависшие сессии при проблемах с сетью, можно добавить общие параметры:

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3

В этом случае клиент будет отправлять проверочный пакет каждые 30 секунд. Если ответ не придет три раза подряд, соединение будет считаться потерянным и автоматически завершится.

Если хотите убедиться, какие именно параметры SSH использует для конкретного подключения после применения всех правил из конфигурации, выполните:

ssh -G prod

Команда покажет итоговую конфигурацию: имя пользователя, адрес сервера, порт, используемый ключ и все остальные параметры после обработки файла ~/.ssh/config. Это один из самых удобных способов проверить, что конфигурация настроена именно так, как вы ожидаете.

🔥 Файл ~/.ssh/config значительно упрощает работу с большим количеством серверов. Он избавляет от длинных команд подключения, позволяет хранить параметры в одном месте, использовать разные SSH-ключи, ProxyJump, нестандартные порты и множество других возможностей OpenSSH, которые делают ежедневную работу администратора или разработчика гораздо удобнее.

🚪 Linux Ready | #практика

В Linux можно ограничить время работы любой команды без написания дополнительной логики!

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

Во многих дистрибутивах уже есть утилита timeout из GNU Coreutils:

bash id="c8fv6n"
$ timeout 30s ./backup.sh

Если через 30 секунд команда не завершится самостоятельно, timeout отправит ей сигнал завершения.

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

bash id="x4pqsn"
$ timeout -s SIGKILL 5m command

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

Команда возвращает код завершения, поэтому её легко использовать в shell-сценариях без дополнительных конструкций.

🔥 timeout позволяет сделать любой сценарий устойчивее к зависаниям буквально одной строкой.

🚪 Linux Ready | #совет

📂 Напоминалка для работы с сетью!

Например, nmcli device wifi list покажет доступные Wi-Fi сети, а nmcli device wifi connect поможет быстро подключиться к нужной точке доступа.

На картинке — команды nmcli для просмотра и настройки сети, управления сетевыми интерфейсами, Wi-Fi и Ethernet-подключениями.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Знали, что можно экспериментировать с mount, вообще не затрагивая основную систему?

Обычно любые операции с mount сразу становятся видны всем процессам в текущем пространстве монтирования. Если случайно смонтировать файловую систему, сделать bind mount или изменить параметры монтирования, изменения увидят и остальные процессы хоста.

Но Linux позволяет создать собственный mount namespace:

sudo unshare --mount --fork bash

Для большинства операций потребуется root (или CAP_SYS_ADMIN).

Новая оболочка получает собственное пространство монтирования. Любые последующие mount, umount и mount --bind будут видны только внутри неё.

Например:

bash id="t8n5wy"
mount -t tmpfs tmpfs /mnt

touch /mnt/test
ls /mnt

Или можно проверить сложный сценарий с bind mount, не опасаясь затронуть основную систему:

mount --bind ./build /usr/local/bin

# Проверяем сценарий...

Когда завершается последний процесс в этом namespace, он автоматически уничтожается вместе со всеми своими mount'ами. Никакой ручной очистки не требуется.

🔥 Если нужно безопасно проверить сложные операции с монтированием или воспроизвести окружение без виртуальной машины и контейнера — unshare --mount является одним из самых удобных инструментов Linux.

🚪 Linux Ready | #совет

📂 Шпаргалка по основным сетевым протоколам!

Например, DNS преобразует доменные имена в IP-адреса, TLS обеспечивает защищённую передачу данных, а SSH используется для безопасного удалённого доступа к системам.

На схеме собраны протоколы, которые встречаются в веб-разработке, сетевой инфраструктуре и системном администрировании: TCP, UDP, QUIC, HTTP, DNS, SSH, WebSocket, WebRTC, WireGuard и другие.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

☁️☁️☁️☁️☁️☁️☁️

24 сентября Yandex Cloud проведёт Yandex Scale 2026 — флагманскую технологическую конференцию, посвящённую облачным технологиям, инфраструктуре и искусственному интеллекту.

🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨
В программе четыре продуктовых трека — AI, Data, Security и Hybrid Infrastructure & DevOps, — и отдельный углублённый технологический трек DeepTech, который пройдёт только онлайн.

В треке Hybrid Infrastructure & DevOps откроем программу рассказом про главные инфраструктурные анонсы и новинки 2026 года. На примере Stackland расскажем, как построить свою внутреннюю платформу по методологии Platform Engineering и ускорить time to market. Разберём, зачем бизнесу кластеры Yandex Managed Service for Kubernetes на тысячи нод — на реальном продакшн-кейсе Mindbox. Расскажем, как получить предсказуемую и безопасную ИИ‑разработку с ИИ‑командой на платформе SourceCraft и максимизировать возврат инвестиций от ИИ. Разберём возможности построения реальной гибридной инфраструктуры на базе единой технологической платформы и то, как полноценно объединить локальную и облачную среды, включая выделенные серверы BareMetal. И на примере крупного банка рассмотрим, как создать полноценный гибрид, соблюдая требования безопасности, регуляторов и бизнеса одновременно.

🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨
Отдельно пройдут воркшопы по Hybrid Infrastructure & DevOps. Смоделируем аварию на физическом сервере и проверим, как гибридная архитектура на облаке и BareMetal держит отказоустойчивость. Научим разворачивать корпоративную ИИ-систему с RAG-сценарием на Yandex BareMetal и Stackland — чтобы модель работала с внутренней документацией и базами знаний. Разберём, как эффективно делить GPU-ресурсы Yandex Managed Service for Kubernetes между параллельными задачами обучения моделей. И покажем, как команда ИИ-агентов SourceCraft проходит путь от бизнес-требований до безопасного релиза — с проверкой на уязвимости на каждом шаге.

🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨

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

Программа целиком — на сайте конференции, регистрация там же, а участие бесплатное!

Знали, что можно экспериментировать с mount, вообще не затрагивая основную систему?

Обычно любые операции с mount сразу становятся видны всем процессам в текущем пространстве монтирования. Если случайно смонтировать файловую систему, сделать bind mount или изменить параметры монтирования, изменения увидят и остальные процессы хоста.

Но Linux позволяет создать собственный mount namespace:

sudo unshare --mount --fork bash

Для большинства операций потребуется root (или CAP_SYS_ADMIN).

Новая оболочка получает собственное пространство монтирования. Любые последующие mount, umount и mount --bind будут видны только внутри неё.

Например:

bash id="t8n5wy"
mount -t tmpfs tmpfs /mnt

touch /mnt/test
ls /mnt

Или можно проверить сложный сценарий с bind mount, не опасаясь затронуть основную систему:

mount --bind ./build /usr/local/bin

# Проверяем сценарий...

Когда завершается последний процесс в этом namespace, он автоматически уничтожается вместе со всеми своими mount'ами. Никакой ручной очистки не требуется.

🔥 Если нужно безопасно проверить сложные операции с монтированием или воспроизвести окружение без виртуальной машины и контейнера — unshare --mount является одним из самых удобных инструментов Linux.

🚪 Linux Ready | #совет