Автоматизация в Linux: Bash-скрипты, Cron, Systemd Timers и Disaster Recovery

1. Основы написания продакшн-скриптов на Bash

Bash (Bourne Again Shell) — это одновременно командная оболочка Linux и скриптовый язык программирования. Он позволяет объединять цепочки терминальных команд в автоматизированные сценарии.

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

Строгий режим исполнения (Safe Mode)

В начале любого автоматизационного скрипта следует задавать шебанг и директиву set -euo pipefail:

#!/usr/bin/env bash

# Строгий режим обработки ошибок
set -euo pipefail

# -e : Прекращает выполнение при любой ошибке (ненулевом коде возврата)
# -u : Считает ошибкой обращение к необъявленным переменным
# -o pipefail : Возвращает код ошибки конвейера (pipe), если упала хотя бы одна команда

Практический пример: Скрипт бэкапа файлов, дампов БД (MySQL/PostgreSQL) и ротации

#!/usr/bin/env bash
set -euo pipefail

LOG_DIR="/var/log/custom-app"
BACKUP_DIR="/var/backups/custom-app"
DATE=$(date +%Y-%m-%d_%H-%M)
DB_NAME="app_db"
DB_USER="backup_user"

# Проверка привилегий root
if [[ $EUID -ne 0 ]]; then
   echo "[ERROR] Скрипт должен запускаться с правами root!" >&2
   exit 1
fi

# Создание директории бэкапа
mkdir -p "${BACKUP_DIR}"

echo "[INFO] Начало резервного копирования: ${DATE}"

# 1. Снятие дампа MySQL/MariaDB
echo "[INFO] Создание дампа MySQL..."
mysqldump -u "${DB_USER}" "${DB_NAME}" | gzip > "${BACKUP_DIR}/mysql-${DB_NAME}-${DATE}.sql.gz"

# 2. Снятие дампа PostgreSQL (альтернативный вариант)
# pg_dump -U postgres -d "${DB_NAME}" | gzip > "${BACKUP_DIR}/pg-${DB_NAME}-${DATE}.sql.gz"

# 3. Архивирование файлов и логов
if [[ -d "${LOG_DIR}" ]]; then
    echo "[INFO] Архивирование файлов логов..."
    tar -czf "${BACKUP_DIR}/logs-${DATE}.tar.gz" -C "${LOG_DIR}" .
fi

# 4. Ротация: удаление локальных архивов старше 7 дней
echo "[INFO] Очистка старых бэкапов..."
find "${BACKUP_DIR}" -type f \( -name "*.tar.gz" -o -name "*.sql.gz" \) -mtime +7 -delete

echo "[INFO] Резервное копирование успешно завершено."

2. Анализ и парсинг текстовых данных (grep, awk, sed, jq)

Быстрый анализ лог-файлов на сервере — базовый навык системного администратора и SOC-аналитика.

grep — поиск строк по шаблонным выражениям (RegEx):

# Поиск ошибок 404 за исключением внутренних IP-адресов
grep " 404 " access.log | grep -v "192.0.2."

awk — обработка структурированных текстовых столбцов:

# Выборка ТОП-5 IP-адресов с наибольшим числом запросов
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -n 5

sed — потоковое редактирование текста и автозамена:

# Автоматическая замена параметров в конфиге
sed -i 's/203.0.113.10/192.0.2.1/g' /etc/nginx/sites-available/default

jq — потоковый парсинг и обработка данных в формате JSON:

# Извлечение статуса из JSON-ответа локального API
curl -s http://localhost:8080/health | jq '.status'

3. Планировщики задач: Cron vs Systemd Timers

Для фонового выполнения регулярных операций применяются службы-планировщики.

Классический Crontab

Настраивается через утилиту crontab -e. Формат времени включает 5 полей: Минута Час ДеньМесяца Месяц ДеньНедели.

# Запуск бэкапа каждый день в 03:00 ночи
0 3 * * * /usr/local/bin/backup-script.sh >> /var/log/backup.log 2>&1

Systemd Timers (Современный стандарт)

Systemd-таймеры превосходят Cron благодаря детальному логированию в journalctl, отслеживанию зависимостей и возможности запуска пропущенных задач через параметр Persistent=true.

Создается пара файлов конфигурации в /etc/systemd/system/:

1. Файл сервиса (backup.service):

[Unit]
Description=Daily System Backup
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-script.sh

2. Файл таймера (backup.timer):

[Unit]
Description=Run backup service daily at 3am

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

# Активация и запуск таймера
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
sudo systemctl list-timers

4. Стратегии бэкапирования и Disaster Recovery

Основа надежного восстановления данных после сбоев — **Правило резервного копирования 3-2-1**:

3 экземпляра важных данных (1 рабочий + 2 резервных).
2 различных типа носителей информации.
1 копия хранится удаленно (Off-site backup / S3 Cloud).

Метрики восстановления (DR):
RTO (Recovery Time Objective) — максимально допустимое время простоя системы от момента аварии до полного восстановления.
RPO (Recovery Point Objective) — максимально допустимый объем потерь данных, измеряемый во времени (например, при ежедневном бэкапе RPO = 24 часа).

Автоматизация передачи бэкапов (Rsync & Rclone)

# Резервное копирование директории на удаленный сервер по SSH через rsync
rsync -avz --delete /var/www/ user@remote-host:/backups/www/

# Синхронизация бэкапа с облачным S3-хранилищем через rclone
rclone sync /var/backups/ s3-storage:company-backups/ --progress

Составление Runbooks (Инструкций по развертыванию из бэкапа)

Runbook — это пошаговое руководство, определяющее порядок действий инженера при аварии. Он исключает человеческий фактор, когда система лежит и требуется вписаться в RTO.

Пример Runbook: Развертывание приложения из нуля после сбоя сервера

Подготовка чистой ОС: Развернуть свежий инстанс Ubuntu 24.04 и установить необходимые пакеты:
```
sudo apt update & sudo apt install -y nginx mysql-server rclone gunzip
```
Получение актуальных бэкапов: Загрузить последние данные из S3-облака:
```
rclone copy s3-storage:company-backups/latest /tmp/restore/
```

Восстановление базы данных:

# Для MySQL:
gunzip < /tmp/restore/mysql-app_db-latest.sql.gz | mysql -u root -p app_db

# Для PostgreSQL:
gunzip < /tmp/restore/pg-app_db-latest.sql.gz | psql -U postgres -d app_db

Восстановление файлов веб-приложения:
```
tar -xzf /tmp/restore/logs-latest.tar.gz -C /var/www/html/
```
Запуск и проверка доступности сервисов:
```
sudo systemctl restart nginx mysql
curl -I http://localhost/health
```

Автоматизация в Linux: Bash-скрипты, Cron vs Systemd Timers и Disaster Recovery