🗄️ Storage: Почему локальные диски умерли. Встречаем S3 (MinIO)

Боль: Ваше приложение (на PHP, Python, Go) позволяет пользователям загружать аватарки.

* Вариант 1: Сохранять в папку /var/www/uploads. (Проблема: Как масштабировать на 2 сервера? Нужен NFS или rsync — это медленно и сложно).

* Вариант 2: Сохранять в базу данных (BLOB). (Проблема: БД раздувается, бэкапы становятся огромными).

Решение: Object Storage (S3 API). Архитектор отделяет хранение (Storage) от вычислений (Compute).

MinIO — это самый популярный self-hosted S3-совместимый сервер.

Почему это круто:

1. Стандарт: S3 API поддерживают все (Veeam, Terraform, все языки программирования).

2. Масштабируемость: MinIO легко собирается в кластер.

3. Простота: Одно приложение для всех файлов.

Запуск (Docker):

docker run -d \
  -p 9000:9000 -p 9001:9001 \
  --name minio \
  -v /mnt/data:/data \
  -e "MINIO_ROOT_USER=admin" \
  -e "MINIO_ROOT_PASSWORD=SuperSecretPassword" \
  minio/minio server /data --console-address ":9001"

Теперь ваше приложение просто шлет PUT запрос на http://minio:9000. И ему всё равно, на каком сервере оно запущено.

Взгляд архитектора: Использование локальной файловой системы для данных приложения — это антипаттерн в современном IT (12-Factor App). Переход на S3 API делает ваши приложения Cloud Native (готовыми к облаку) сразу.

#devops #storage #s3 #minio #docker #architect #гайд

📦 Бэкапы: Проверяем связку Veeam + Synology S3 перед выходными 🗄

Уйти на выходные, не проверив бэкапы — это преступление против своей нервной системы. Особенно если у тебя настроено модное резервное копирование серверов через Veeam в S3-хранилище (например, на удаленный NAS Synology с включенной неизменяемостью Object Lock).

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

Сниппет для быстрой проверки (запускаем на сервере Veeam):

Add-PSSnapin VeeamPSSnapIn -ErrorAction SilentlyContinue

# Вытаскиваем все джобы за последние 24 часа и подсвечиваем ошибки
Get-VBRBackupSession | 
    Where-Object { $_.CreationTime -ge (Get-Date).AddDays(-1) } | 
    Select-Object JobName, Result, @{Name="Duration";Expression={$_.EndTime - $_.CreationTime}}, State | 
    Sort-Object Result -Descending | 
    Format-Table -AutoSize

Куда смотреть:

Если в колонке Result видишь Failed с ошибкой доступа к S3 — срочно проверяй сертификаты на Synology или права сервисного аккаунта бакета.
Если везде Success — бэкап Шредингера жив, инфраструктура в безопасности.

#veeam #synology #s3 #backup #disasterrecovery #powershell #sysadmin #admin_future

📦 S3 vs FTP: Почему пора перестать гонять файлы по старинке

Многие по привычке воспринимают S3 (Object Storage) как просто «бесконечную флешку в интернете». Но если копнуть глубже, разница между ним и обычным файловым сервером (FTP/SFTP/NFS) огромна.

1. Иерархия против Плоской структуры

FTP (File Storage): Это дерево. Папки, подпапки, файлы. Если у тебя миллион файлов в одной директории, команда ls или попытка открыть её через клиент заставит сервер «призадуматься» на пару минут.
S3 (Object Storage): Здесь нет папок. Вообще. Есть только Bucket (корзина) и Key (ключ/путь). То, что ты видишь как /uploads/2026/march/photo.jpg — это просто длинное имя одного объекта. Это позволяет S3 находить любой файл среди миллиардов других за фиксированное время.

2. Протоколы и Доступ

FTP: Это отдельный протокол, порты 21 (или 22 для SFTP), проблемы с пассивным режимом и фаерволами.
S3: Это HTTP/HTTPS. Твой файл — это URL. Доступ к нему осуществляется через стандартные REST API запросы (GET, PUT, DELETE). Это делает S3 идеальным для веба: браузеры и мобильные приложения общаются с ним «на одном языке».

3. Масштабируемость и Отказоустойчивость

FTP: Ты ограничен объемом диска на сервере. Кончилось место? Покупай новый диск, расширяй раздел, делай LVM. Упал сервер — файлы недоступны.
S3: Он практически бездонен. Тебе не нужно думать о месте. Более того, облачные провайдеры (AWS, Selectel, Yandex Cloud) реплицируют твои данные между разными дата-центрами. Вероятность потери данных в S3 стремится к нулю.

4. Метаданные

FTP: У файла есть размер и дата изменения. Всё.
S3: Ты можешь прицепить к объекту любые метаданные: Content-Type, Author, Project-ID или даже свои кастомные теги. По этим тегам потом можно настраивать политики автоматического удаления или перемещения в «холодное» (дешевое) хранилище.

🛠 Инструмент админа: rclone
Если тебе нужно перекинуть данные с древнего FTP в современное S3-хранилище, не мучайся со скриптами. Используй rclone — это «швейцарский нож» для облаков.
Команда для синхронизации:

# Настраиваем конфиг через rclone config, а затем:
rclone sync my_ftp:/var/www/uploads my_s3_bucket:backup-2026 -P

Когда НЕ нужен S3?
Если твоей программе нужно постоянно открывать файл, менять в нем одну строчку и сохранять (например, база данных SQLite или редактирование кода «на лету») — S3 не подойдет. Он работает по принципу «перезапиши объект целиком».

#storage #s3 #ftp #cloud #devops #sysadmin #rclone #admin_future

🐧 Linux: Proxmox Backup Server 4.2 — S3 из preview стал production, и вот что это меняет

Коллеги, 30 апреля вышел Proxmox Backup Server 4.2 — и это один из тех релизов, где changelog стоит читать внимательно, а не по диагонали.

Три главных изменения для тех кто держит инфраструктуру на Proxmox:

S3-совместимые объектные хранилища теперь официально поддерживаются как backend для бэкапов. Появились счётчики запросов и статистика трафика прямо в сводке datastora — это помогает рано замечать неожиданные всплески трафика. Wasabi, Backblaze, MinIO, RustFS — всё это теперь не "экспериментально", а production-ready.

Push sync jobs теперь могут шифровать снапшоты на лету перед отправкой на удалённый datastore — для сценариев когда принимающий сервер находится в менее доверенной среде. Pull sync jobs симметрично умеют расшифровывать. Ключи для tape и sync теперь управляются из единой панели.

Sync jobs теперь обрабатывают несколько групп параллельно через новый параметр worker-threads. Это увеличивает throughput на высоколатентных линках и помогает обойти ограничения HTTP/2 соединений.

Под капотом: Debian 13.4 Trixie, Linux kernel 7.0 как стабильный default, ZFS 2.4.

# Обновляем существующую установку через APT:
apt update && apt dist-upgrade -y

# Проверяем версию после обновления:
pbs-manager version

# Настраиваем S3 datastore через API (или через WebUI):
# Storage -> Add -> S3-Compatible Storage
# Указываем: bucket, endpoint, access key, secret key, region

# Настраиваем параллельные потоки для sync job (в WebUI):
# Datastore -> Sync Jobs -> Edit -> Worker Threads: 4
# Рекомендуется: 2-8 в зависимости от количества групп и ширины канала

# Проверяем статистику S3 datastora:
# Storage -> [datastore name] -> Summary -> Request Counters
# Мониторим API requests/day и transfer bytes

# Включаем шифрование sync job:
# Sync Job -> Edit -> Encryption -> Enable
# Выбираем ключ (создать: Configuration -> Sync Encryption Keys)

Зачем это важно:
Стратегия 3-2-1 становится реальной без дорогих решений: быстрые локальные бэкапы на основном хранилище PBS, копии в S3 для офсайт-защиты. Теперь это не хак через rclone, а встроенная функция с мониторингом и шифрованием.

Итог: PBS 4.2 — апгрейд без поводов откладывать. Особенно если уже смотрели на S3 как on offsite target.

#linux #proxmox #backup #s3 #storage #sysadmin #admin_future