Серверы для удаленных резервных копий и бакетов S3

Четыре диска по 16 ТБ можно организовать тремя способами:

• Два зеркала (RAID 10): 32 ТБ полезного объема, самое быстрое перестроение и лучший случайный ввод-вывод; выдерживает отказ одного диска в каждом зеркале.
• RAIDZ2 или mdadm RAID 6: те же 32 ТБ полезного объема, но массив выдерживает отказ любых двух дисков. Для хранилища резервных копий это обычно правильный выбор.
• RAIDZ1 или RAID 5: 48 ТБ полезного объема, но второй отказ во время долгого перестроения диска на 16 ТБ означает потерю всех данных.

Утилиты покажут 32 ТБ примерно как 29.1 ТиБ; пулы ZFS лучше заполнять не более чем примерно на 80%. Два NVMe-диска по 512 ГБ могут вместить ОС и — в зеркале — vdev ZFS типа special для метаданных, что ускоряет работу репозиториев с большим количеством чанков. Потеря этого vdev означает потерю всего пула, поэтому никогда не размещайте его на одном диске.

Правило 3-2-1 предписывает хранить три копии на двух типах носителей, причем одну — вне основной площадки. Но сегодня куда больший риск — злоумышленник с root-доступом к продакшену, который удаляет резервные копии с помощью найденных там учетных данных. Перекройте этот путь:

• Ограничьте SSH-ключ каждого клиента командой borg serve --append-only через forced command в authorized_keys или используйте rest-server --append-only из проекта restic.
• В Proxmox Backup Server выдайте хостам токен с ролью DatastoreBackup, которая позволяет добавлять резервные копии, но не удалять их, а очистку (prune) запускайте на самом сервере.
• Делайте снапшоты ZFS на самом сервере резервных копий, где клиенты не могут до них добраться.
• Запланируйте тестовые восстановления. Резервная копия, из которой никто ни разу не восстанавливался, — всего лишь гипотеза.

MinIO, Garage и SeaweedFS поддерживают S3 API, поэтому restic, Kopia, rclone, pgBackRest и большинство инструментов резервного копирования могут писать в них без каких-либо изменений. На одном сервере:

• Пусть за избыточность отвечает только один уровень. Либо отдайте объектному хранилищу «сырые» диски и его собственный механизм erasure coding, как в многодисковом режиме MinIO, либо запустите его поверх массива ZFS или mdadm — но не то и другое сразу.
• Garage и SeaweedFS по-настоящему раскрываются, когда вы добавляете второй или третий узел в другой локации для репликации.
• Терминируйте TLS на nginx или Caddy и выдайте каждому клиенту отдельный ключ доступа, ограниченный его собственным бакетом.
• Включите версионирование или блокировку объектов (object lock), если хранилище их поддерживает, чтобы перезаписанные объекты можно было восстановить.