😑 tmpfs: где ускоряет систему, а где создает проблемы

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

▪️ Посмотреть текущие tmpfs:

df -h -t tmpfs

/run
/dev/shm
/tmp

Главный плюс tmpfs - скорость. Операции чтения и записи обычно быстрее, чем на диске, особенно если это много мелких временных файлов.

▪️ Где tmpfs полезен:

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

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

mkdir -p /mnt/ramtmp

mount -t tmpfs -o size=2G tmpfs /mnt/ramtmp

Теперь /mnt/ramtmp будет tmpfs с лимитом 2 ГБ.

Для постоянного подключения через /etc/fstab:

tmpfs /mnt/ramtmp tmpfs defaults,size=2G,noatime 0 0

▪️ tmpfs легко становится источником проблем.

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

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

df -h /mnt/ramtmp

И отдельно смотреть память:

free -h

Третья проблема - OOM. Если приложение активно пишет во временный каталог на tmpfs, можно неожиданно упереться в память.
Особенно на серверах с тяжелыми сервисами, контейнерами или сборками.

Четвертая проблема - swap. Если swap включен, tmpfs не всегда означает "только RAM". Под давлением памяти часть страниц может уехать в swap, и внезапно "быстрый tmpfs" станет не таким быстрым.

▪️ Где лучше быть осторожным:

• /tmp на серверах с непредсказуемыми задачами;
• директории аплоадов;
• временные файлы баз данных;
• CI/CD-сборки без лимитов;
• контейнеры с активной записью;
• любые каталоги, где размер данных заранее неизвестен.

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

[Service]
PrivateTmp=true

Это даст сервису отдельный /tmp и /var/tmp, чтобы он не мешал другим процессам. А если нужен runtime-каталог:

[Service]
RuntimeDirectory=myapp

Тогда systemd создаст каталог в /run, который обычно тоже находится на tmpfs.

#linux #tmpfs

🧑‍💻 NetworkAdmin

🌟 psmisc toolkit: fuser, pstree, killall в реальной админке

psmisc - небольшой набор утилит, которые часто оказываются полезнее, чем кажутся на первый взгляд. Обычно пакет ставят ради трех команд: fuser, pstree, killall

▪️ Установка:

apt install psmisc
# или:
yum install psmisc

▪️ fuser: кто держит файл, порт или mount point. fuser показывает процессы, которые используют файл, каталог, сокет или файловую систему. Например, не получается размонтировать диск:

umount /mnt/backup

А в ответ: target is busy

Смотрим, кто держит mount point:

fuser -vm /mnt/backup

Можно увидеть PID, пользователя и тип доступа. Если нужно аккуратно завершить процессы:

fuser -k /mnt/backup

Но с -k лучше не спешить. Сначала посмотреть, потом убивать.

Еще полезный пример - кто держит TCP-порт:

fuser -v 8080/tcp

Или UDP:

fuser -v 53/udp

▪️ pstree: дерево процессов вместо каши. ps aux часто превращается в простыню. pstree показывает процессы в виде дерева: кто кого запустил и где родительский процесс.

pstree

С PID:

pstree -p

Для конкретного пользователя:

pstree -u username

Для конкретного процесса:

pstree -p 1234

Это очень удобно, когда нужно понять:

• какой процесс породил дочерние
• кто держит worker’ы
• почему после остановки сервиса остались потомки
• откуда запущен странный процесс
• что происходит внутри shell-сессии или скрипта

Например, при зависшем deploy можно быстро увидеть цепочку:

sshd───bash───deploy.sh───rsync

И уже понятно, кого действительно нужно трогать.

▪️ killall: завершить процессы по имени. killall убивает процессы по имени, а не по PID. Например:

killall nginx

или мягко через TERM:

killall -TERM nginx

Если процесс не реагирует:

killall -KILL nginx

Но KILL - это крайний вариант. Сначала лучше отправлять TERM, чтобы процесс мог корректно завершиться. Можно посмотреть, что будет затронуто:

pgrep -a nginx

А уже потом использовать killall.

killall работает по имени процесса. Если на сервере есть несколько процессов с одинаковым именем, можно задеть лишнее.
Особенно осторожно с короткими именами и системными процессами.
Хороший порядок в админке такой:

fuser -vm /mnt/backup
pstree -p
pgrep -a process_name
killall -TERM process_name

Сначала понять, кто держит ресурс. Потом посмотреть дерево процессов. И только потом что-то завершать.

#linux #psmisc

🧑‍💻 NetworkAdmin

👍 Sysinternals без скачивания: подключаем как сетевой диск

Короткая, но полезная штука для админов Windows. У Sysinternals есть live-каталог, который можно подключить как сетевой диск и запускать утилиты напрямую, без ручного скачивания архива. Команда простая:

net use S: http://live.sysinternals.com/tools

Если все прошло нормально, Windows ответит: Команда выполнена успешно.

После этого у вас появляется диск S:, где лежат утилиты Sysinternals.
Переходим на него:

S:

И запускаем нужный инструмент:

procexp64.exe

Для тех, кто не пользовался Sysinternals: это старый и очень известный набор утилит microsoft для диагностики и администрирования windows.

▪️ Что там особенно полезно:

• Process Explorer. Расширенный менеджер процессов. Показывает дерево процессов, потоки, DLL, handles, параметры запуска, цифровые подписи, сетевую активность и много другой информации.

procexp64.exe

• TCPView. Показывает сетевые соединения: какой процесс, куда подключился, какой порт использует и в каком состоянии соединение.

tcpview.exe

• Autoruns. Один из лучших инструментов для разбора автозагрузки. Показывает Run-ключи, службы, драйверы, scheduled tasks, shell extensions и многое другое.

Autoruns.exe

• PsExec. Утилита для удаленного запуска процессов на Windows-хостах.

PsExec.exe

• Handle. Помогает понять, какой процесс держит файл или каталог.

handle.exe

Такой способ особенно удобен, когда нужно быстро что-то проверить на сервере или рабочей станции, а заранее набор утилит не скачан. Закончили работу - отключаем диск:

net use S: /delete

❗️ Запускать инструменты напрямую из интернета удобно, но не всегда уместно. В корпоративной среде могут быть ограничения: прокси, firewall, AppLocker / WDAC, запрет WebDAV, требования к контролю версий утилит и т.д.

#windows #sysinternals

🧑‍💻 NetworkAdmin

❓ SSHFS-Win: подключаем Linux-каталог как диск в Windows

В Windows можно подключать каталоги с удаленного linux/unix-сервера как обычный сетевой диск. Не через SMB, не через FTP и не через WebDAV, а по защищенному SSH-соединению. Для этого есть SSHFS-Win - порт SSHFS-клиента для Windows. Он позволяет монтировать удаленную файловую систему по SSH так, будто это обычный диск в Проводнике.

После установки SSHFS-Win каталог можно подключить прямо из Проводника Windows. Например, UNC-путь:

\\sshfs.r\administrator@192.168.158.100\remote_folder

sshfs.r - тип подключения
administrator - пользователь на удаленном сервере
192.168.158.100 - адрес сервера
remote_folder - удаленный каталог

Можно смонтировать диск и из командной строки:

net use M: \\sshfs.r\administrator@192.168.158.100\ps /user:administrator

После этого в системе появится диск M:, с которым можно работать как с обычным сетевым диском.

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

\\sshfs.k\administrator@192.168.158.100\remote_folder

Префикс sshfs.k говорит SSHFS-Win использовать ключевую аутентификацию. Это удобнее и безопаснее, чем постоянно вводить пароль, особенно если доступ нужен регулярно.

Пример подключения по ключу:

net use M: \\sshfs.k\administrator@192.168.158.100\remote_folder

Отключить диск можно стандартно:

net use M: /delete

▪️ Где SSHFS-Win особенно полезен:

• админ работает на Windows, а серверы linux;
• нужно быстро открыть /var/log или /etc;
• нет желания поднимать samba;
• нужен доступ к файлам через уже разрешенный SSH;
• удобно подключать dev/test каталоги;
• нужно временно смонтировать удаленную папку без лишней инфраструктуры.

SSHFS-Win - это не замена нормальному файловому серверу для большой команды. Для постоянной совместной работы, офисных файлов и тяжелой нагрузки чаще лучше использовать SMB/NFS/специализированное хранилище. Но для админских задач SSHFS-Win очень удобен: есть SSH-доступ - есть и сетевой диск в windows. Главное - использовать ключи, ограничивать права пользователя на сервере и не монтировать под root то, что можно открыть обычной учеткой.

#windows #sshfs

🧑‍💻 NetworkAdmin

Лапшу заказывали?

#юмор

🧑‍💻 NetworkAdmin

С днём системного администратора! 🏆

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

Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷

🧑‍💻 NetworkAdmin

💚 Linux capabilities: как дать процессу нужные права без полного root

Одна из старых проблем linux- приложение либо работает от обычного пользователя, либо получает полный root. Но на практике многим сервисам нужен всего один привилегированный доступ. Например:

• открыть порт ниже 1024;
• работать с raw-сокетами;
• менять сетевые настройки;
• выполнять отдельные системные операции.

Давать ради этого полный root - не лучшая идея. Для таких случаев в Linux существуют capabilities. Они разбивают привилегии суперпользователя на отдельные возможности, которые можно выдавать выборочно. К примеру, веб-серверу нужен только доступ к 80 порту. Без root обычный пользователь не сможет открыть этот порт:

python3 -m http.server 80

# Получим ошибку:
Permission denied```

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

setcap cap_net_bind_service=+ep /usr/bin/python3

Проверяем:

getcap /usr/bin/python3

Результат:

/usr/bin/python3 cap_net_bind_service=ep

Теперь процесс сможет слушать порт 80 без запуска от root. Еще несколько популярных capabilities:

• CAP_NET_BIND_SERVICE - порты ниже 1024
• CAP_NET_RAW - raw sockets, ping и подобные инструменты
• CAP_SYS_TIME - изменение системного времени
• CAP_NET_ADMIN - управление сетью
• CAP_SYS_ADMIN - очень широкие административные возможности (почти mini-root)

Посмотреть capabilities процесса:

cat /proc/<PID>/status | grep Cap

Или использовать:

capsh --print

Удалить capability:

setcap -r /usr/bin/python3

Очень полезны capabilities и в systemd. Например, сервис работает от непривилегированного пользователя:

[Service]
User=nginx
AmbientCapabilities=CAP_NET_BIND_SERVICE

В итоге процесс не получает root, но может слушать 80 и 443 порты. Это гораздо безопаснее, чем запускать весь сервис от суперпользователя. Но не все capabilities одинаково безопасны. Например: CAP_SYS_ADMIN настолько мощная, что ее часто называют новым root. Поэтому принцип тот же, что и с правами пользователей: выдаем минимум необходимого.

Если приложению нужен только доступ к порту 80 - выдаем только CAP_NET_BIND_SERVICE. Не нужно на всякий случай раздавать весь набор возможностей.

#linux #security #capabilities

🧑‍💻 NetworkAdmin

🔖 DNS TTL: почему запись поменяли, а пользователи всё еще идут на старый IP

Классическая ситуация при миграции сервиса: DNS-запись уже поменяли. На авторитативном DNS новый IP виден. А часть пользователей все равно попадает на старый сервер.

Первое желание - это сказать: "DNS не обновился." Но чаще всего DNS как раз работает правильно. Просто сработал TTL. TTL - это Time To Live, время жизни DNS-записи в кэше. Когда резолвер получил ответ, он имеет право хранить его указанное количество секунд и не спрашивать авторитативный DNS заново. Например:

app.networkadmin.ru.  3600  IN  A  203.0.113.10

3600 означает, что запись можно кэшировать 3600 секунд, то есть 1 час. Если вы поменяли IP через 5 минут после того, как чей-то DNS-резолвер закэшировал старый ответ, он может продолжать отдавать старый IP до истечения TTL. И это нормально.

▪️ Где может застрять старый DNS-ответ:

• recursive DNS провайдера
• корпоративный DNS
• DNS-кэш на роутере
• локальный кэш ОС
• браузер
• приложение с собственным DNS-кэшем
• контейнер или runtime
• CDN / reverse proxy

Поэтому один пользователь уже видит новый IP, а другой - старый.

▪️ Проверка. Проверять лучше не просто через ping, а через dig. Посмотреть текущий ответ обычного резолвера:

dig app.networkadmin.ru

Спросить конкретный публичный DNS:

dig @8.8.8.8 app.networkadmin.ru
dig @1.1.1.1 app.networkadmin.ru

Спросить авторитативный DNS напрямую:

dig NS networkadmin.ru
dig @ns1.networkadmin.ru app.networkadmin.ru

Во время диагностики важно смотреть не только IP, но и оставшийся TTL:

app.networkadmin.ru.  1842  IN  A  203.0.113.10

Если TTL уменьшается - это кэшированный ответ. Если на авторитативном DNS уже новый IP, а у клиента старый - значит где-то по пути еще живет старый кэш.

▪️ Как правильно готовить миграцию:

• Заранее уменьшить TTL, например до 60–300 секунд.
• Подождать старый TTL, чтобы старые кэши успели обновиться.
• Поменять DNS-запись.
• Проверить ответы с разных резолверов.
• Не выключать старый сервер сразу.

Например, если сейчас TTL был 24 часа, нельзя просто поставить TTL 60 и через минуту ждать мгновенного переключения. Сначала нужно дождаться, пока старое значение TTL доживет в кэшах.

▪️ Частая ошибка:

• Сегодня в 12:00 TTL был 86400
• Сегодня в 12:05 поставили TTL 60
• Сегодня в 12:10 поменяли IP

А пользователи все еще могут ходить на старый IP до следующего дня, потому что часть резолверов закэшировала запись еще с TTL 86400.

#dns #ttl #network

🧑‍💻 NetworkAdmin

🔥 Короткий вывод IP-адресов без простыни

В linux давно уже привычнее смотреть сетевые настройки через ip, а не через старый ifconfig. Обычно для просмотра адресов используют:

ip a

Команда рабочая, подробная, показывает все. Но иногда этого "все" слишком много. Нужно быстро увидеть:

• интерфейсы
• их состояние
• IPv4/IPv6 адреса
• без лишних строк и простыни вывода

Для этого у ip есть очень удобный ключ:

ip -br a

-br означает brief, то есть краткий вывод.

▪️ Пример:

ip -br a

lo       UNKNOWN  127.0.0.1/8 ::1/128
eth0     UP       172.18.107.235/20 fe80::215:5dff:fe0d:7101/64
eth1     UP       192.168.101.2/24 fe80::215:5dff:fe0d:7105/64
docker0  DOWN     172.17.0.1/16

Сразу видно, какой интерфейс поднят, какой адрес назначен и где есть IPv6.

▪️ Если нужны только IPv4-адреса:

ip -br -4 a

lo       UNKNOWN  127.0.0.1/8
eth0     UP       172.18.107.235/20
eth1     UP       192.168.101.2/24
docker0  DOWN     172.17.0.1/16

▪️ Только IPv6:

ip -br -6 a

Это реально удобнее, когда на сервере много интерфейсов: физические NIC, VLAN, bridge, docker-сети, loopback. Не нужно глазами вылавливать IP среди десятков строк. Краткий режим работает не только с адресами.

▪️ Посмотреть интерфейсы и MAC-адреса:

ip -br link

или короче:

ip -br l

▪️ Посмотреть соседей ARP/Neighbor Cache:

ip -br neigh

или:

ip -br n

▪️ Маршруты, как обычно:

ip r

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

ip route get 8.8.8.8

Это часто полезнее, чем просто смотреть всю таблицу маршрутизации.

▪️ Что стоит запомнить:

ip -br a
ip -br -4 a
ip -br -6 a
ip -br l
ip -br n
ip r
ip route get 8.8.8.8

#linux #network

🧑‍💻 NetworkAdmin

⚙️ MBR2GPT: как перевести Windows с Legacy BIOS на UEFI без переустановки

Иногда windows на современном железе оказывается установленной в режиме Legacy BIOS / CSM. Работает и ладно. Но есть нюанс: для нормальной UEFI-загрузки нужен диск с таблицей разделов GPT, а не старый MBR. Почему вообще стоит переходить на UEFI + GPT:

• поддержка дисков больше 2 ТБ;
• больше 4 основных разделов без костылей;
• современный механизм загрузки;
• поддержка Secure Boot;
• меньше зависимости от режима совместимости CSM.

Secure Boot особенно важен: он помогает защититься от подмены загрузчика и запуска вредоносного кода до старта ОС. Если Windows уже установлена в legacy-режиме, не всегда нужно переустанавливать систему. Начиная с Windows 10 1703, есть встроенная утилита:

mbr2gpt

Она умеет конвертировать системный диск из MBR в GPT без удаления данных. Сначала проверяем, в каком режиме загружена Windows:

$env:firmware_type

Если видим: Legacy, значит система загружена в режиме совместимости.

▪️ Проверяем разметку диска и разделы:

Get-Disk | Get-Partition

Важно: на системном MBR-диске обычно должно быть не больше 3 первичных разделов, потому что mbr2gpt нужно место для создания EFI System Partition.

▪️ Проверяем возможность конвертации:

mbr2gpt /validate /allowFullOS

▪️ Если проверка прошла успешно, запускаем конвертацию:

mbr2gpt /convert /allowFullOS

После этого утилита:

• проверит структуру диска
• создаст EFI-раздел
• сконвертирует MBR в GPT
• добавит UEFI-загрузчик Windows
• обновит загрузочные данные

Дальше нужно перезагрузить компьютер или сервер и зайти в настройки прошивки. Там меняем режим загрузки: Legacy / CSM -> UEFI
Если есть опция boot order, выбираем Windows Boot Manager для нужного диска. После успешной загрузки можно снова проверить режим:

$env:firmware_type

Теперь должно быть: UEFI

#windows #uefi #gpt

🧑‍💻 NetworkAdmin

За пачку вискаса все настрою 😮

#юмор

🧑‍💻 NetworkAdmin

▶️ systemd socket activation: запуск сервиса только при реальном запросе

Обычно сервис в linux запускается заранее и постоянно висит в памяти:

systemctl start myapp

Даже если к нему никто не обращается, процесс уже работает, занимает ресурсы и ждет подключения. Но в systemd есть другой подход - socket activation. Идея простая:

• systemd заранее открывает socket или порт;
• сам сервис пока не запущен;
• приходит первый запрос;
• systemd стартует сервис;
• сервис получает уже открытое соединение или socket.

То есть приложение запускается не на всякий случай, а только когда к нему реально обратились. Классический пример - ssh.socket, cups.socket, docker.socket и разные локальные демоны.

Посмотреть активные сокеты:

systemctl list-sockets

Статус конкретного socket-unit:

systemctl status myapp.socket

▪️ Пример. Создаем /etc/systemd/system/myapp.socket:

[Unit]
Description=MyApp socket

[Socket]
ListenStream=8080

[Install]
WantedBy=sockets.target
И сервис /etc/systemd/system/myapp.service:
[Unit]
Description=MyApp service

[Service]
ExecStart=/usr/local/bin/myapp

Включаем именно сокет, а не service:

systemctl daemon-reload
systemctl enable --now myapp.socket

Теперь порт 8080 уже слушается, но сам myapp.service может быть не запущен. Проверяем:

ss -lntp | grep 8080
systemctl status myapp.service

Как только придет подключение на порт 8080, systemd запустит myapp.service.

▪️ Зачем это нужно:

• экономия ресурсов;
• ленивый запуск редко используемых сервисов;
• ускорение boot-процесса;
• возможность принимать соединения до старта приложения;
• меньше ручной логики вокруг кто должен стартовать первым;
• удобная модель для локальных демонов и admin-инструментов.

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

Socket activation работает не только с TCP-портами. Можно слушать Unix socket:

[Socket]
ListenStream=/run/myapp.sock

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

#systemd #socketactivation

🧑‍💻 NetworkAdmin

🌀 Retry-логика в bash: как аккуратно повторять нестабильные операции

В админских скриптах не все ошибки означают, что все окончательно сломалось. Иногда команда падает из-за временной проблемы:

• сеть моргнула;
• API вернул timeout;
• DNS не ответил с первого раза;
• файл еще не появился;
• сервис еще не успел подняться;
• удаленный хост временно недоступен.

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

🤩 Плохой вариант:

curl -fsS https://api.networkadmin.ru/deploy

Если запрос один раз упал - весь скрипт завершился.

🤩 Лучше сделать повтор:

for i in {1..5}; do
  if curl -fsS https://api.networkadmin.ru/deploy; then
    echo "success"
    break
  fi

  echo "attempt $i failed, retrying..."
  sleep 5
done

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

🤩 Более аккуратный вариант - вынести retry в функцию:

retry() {
  local max_attempts="$1"
  local delay="$2"
  shift 2

  local attempt=1

  until "$@"; do
    if (( attempt >= max_attempts )); then
      echo "command failed after $attempt attempts: $*" >&2
      return 1
    fi

    echo "attempt $attempt failed, retrying in ${delay}s..." >&2
    sleep "$delay"
    ((attempt++))
  done
}

Теперь можно использовать так:

retry 5 3 curl -fsS https://api.networkadmin.ru/health

Или дождаться доступности сервиса:

retry 10 2 nc -z 127.0.0.1 5432

5 или 10 - количество попыток
3 или 2 - пауза между попытками
дальше идет команда, которую нужно повторять

▪️ Для операций с сетью часто полезен backoff - увеличение паузы после каждой ошибки:

retry_backoff() {
  local max_attempts="$1"
  local delay="$2"
  shift 2

  local attempt=1

  until "$@"; do
    if (( attempt >= max_attempts )); then
      echo "command failed after $attempt attempts: $*" >&2
      return 1
    fi

    echo "attempt $attempt failed, retrying in ${delay}s..." >&2
    sleep "$delay"

    delay=$((delay * 2))
    ((attempt++))
  done
}

Пример:

retry_backoff 5 2 curl -fsS https://api.networkadmin.ru/status

Паузы будут примерно такими: 2s -> 4s -> 8s -> 16s

Это лучше, чем агрессивно долбить нестабильный сервис каждые 100 мс.

#bash #automation

🧑‍💻 NetworkAdmin

📎 rsync: полезные ключи для бэкапов и аккуратной синхронизации

rsync - одна из тех утилит, которые годами живут в админских скриптах и не теряют актуальности. Ее любят за простую идею: сравнить источник и приемник, а потом скопировать только то, что реально изменилось. Особенно хорошо rsync показывает себя на каталогах с большим количеством файлов. Если нужно синхронизировать два хранилища с сотнями тысяч или миллионами объектов, обычное копирование быстро превращается в боль. У rsync есть минусы. Главный - он не становится магически многопоточным. Но для задач, где нужно копировать файлы как есть, без упаковки, дедупликации и сложных backup-форматов, это все еще очень удобный инструмент. Ниже несколько ключей, которые полезно помнить.

▪️ --backup и --backup-dir. Обычно при синхронизации мы хотим привести приемник к состоянию источника. Например:

rsync -av --delete source/ dest/

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

--backup
--backup-dir=/path/to/old-files

Пример:

rsync -av --delete --backup \
  --backup-dir="/mnt/data/backup/bases_increment/$(date +%F)/" \
  back_user@10.20.5.22:/var/lib/pgpro/backup/ \
  /mnt/data/backup/bases/ \
  >> "/var/log/rsync/1Csrv-$(date +%F).log"

• новые файлы попадут в основной каталог бэкапа;
• файлы, которые должны быть удалены или заменены, будут перемещены в backup-dir;
• изменения за конкретный день окажутся в отдельной папке;
• глубину хранения можно потом регулировать через find.

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

▪️ --progress. Ключ показывает прогресс копирования файлов:

rsync -av --progress source/ dest/

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

rsync -av --info=progress2 source/ dest/

или вообще убрать прогресс из cron-задачи.

▪️ --ignore-existing. Этот ключ полезен, когда нужно восстановить только отсутствующие файлы и не трогать то, что уже есть в целевой директории.
Например, кто-то удалил часть файлов в /var/www, а мы хотим вернуть недостающее из бэкапа:

rsync -av --ignore-existing \
  back_user@10.30.7.5:/mnt/backup/www/ \
  /var/www/

• отсутствующие файлы будут скопированы;
• существующие файлы не будут перезаписаны;
• даже если в бэкапе версия новее, rsync ее не тронет.

Это хороший вариант для аккуратного "докинуть недостающее".

▪️ --update. Копирует файл только если версия в источнике новее, чем в приемнике.

rsync -av --update \
  back_user@10.30.7.5:/mnt/backup/www/ \
  /var/www/

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

▪️ --dry-run. Один из самых важных ключей, особенно если в команде есть --delete.

rsync -av --delete --dry-run source/ dest/

или короче:

rsync -avn --delete source/ dest/

--dry-run показывает, что rsync сделал бы, но ничего реально не меняет. Это спасает от классической ошибки: перепутали источник и приемник - и удалили не там. Перед первой настройкой бэкапа или синхронизации лучше всегда запускать тестовый прогон.

▪️ Отдельно стоит помнить про слеш в конце пути.

rsync -av /data/source/ /backup/source/

копирует содержимое каталога source. А так:

rsync -av /data/source /backup/

копирует сам каталог source внутрь /backup. На первый взгляд мелочь, но из-за этого часто получают не ту структуру директорий.

#linux #rsync

🧑‍💻 NetworkAdmin