​​Дам несколько советов по организации структуры бэкапов на основе своего опыта. На всякий случай напомню, что у меня не обучающий канал. Я не ставлю себе цели выверить информацию, дать максимально подробно и правильно, чтобы вы смогли повторить за мной. Я делюсь своими знаниями, какие они есть. Специально к публикациям не готовлюсь, в основном пишу экспромтом.

Существуют два принципиально разных подхода к созданию бэкапов:

1️⃣ На целевые сервера с данными устанавливаются какие-то агенты единой системы или самостоятельный софт для подготовки и передачи бэкапов в какое-то хранилище. У этого подхода есть несколько плюсов.

➕ Основной - можно локально задавать политики хранения и ротации бэкапов. Не нужен какой-то единый центр управления для этого, а в качестве бэкенда хранения достаточно будет любого сетевого хранилища, куда можно просто складывать данные. Например, хранилище на базе протокола S3. Сейчас это очень распространённые хранилища.

➕ Второе преимущество - достаточно настроить только доступ к хранилищу бэкапов. К самим серверам со стороны хранения доступ настраивать не обязательно. Это актуально в сильно распределённой системе.

➖ Основной минус такого подхода - если скомпрометируют сервер, то злоумышленники могут с него уничтожить и бэкапы. Вероятность такого развития событий не такая уж и маленькая. Некоторые злоумышленники этим промышляют. Сначала каким-то образом в автоматическом режиме получают доступы к серверам, а потом уже руками туда заходят и начинают разбираться, как там всё устроено. Если получают доступ к бэкапам, то шифруют их тоже. Я знаю такие истории.

В таком режиме можно настроить бэкапы с помощью nxs-backup, restic, borg и многих других консольных программ из мира Linux. Получается максимально дёшево и эффективно.

2️⃣ Другой подход - это когда вы имеете сервер для бэкапов, который сам ходит по целевым машинам и забирает с них данные.

➖ Сразу скажу очевидный минус. Сервер бэкапов должен иметь прямой доступ к серверам с данными. Иногда это бывает хлопотно организовать. Иметь где-то во внешней площадке сервер с бэкапами, куда есть доступ у всех целевых серверов проще, чем сделать с внешней площадки доступ ко всем серверам с данными, особенно если они разрозненно находятся.

➖ Второй момент. Для такой схемы недостаточно просто купить какое-то хранилище с доступом по S3, SMB, NFS и т.д. Это должен быть полноценный сервер.

➕ Плюс тут тоже очевиден - это более безопасный способ хранения бэкапов, так как с целевых серверов нет доступа к архивам. При этом сам сервер с бэкапами на целевые сервера может иметь доступ только на чтение. Даже если он будет скомпрометирован, уничтожить исходные данные не получится. Проще всего такое хранение организовать с помощью rsync и доступа по ssh. Создаём на сервере бэкапов ключ, на серверы с данными добавляем учётку с аутентификацией по этому ключу и забираем данные по ssh. Подойдёт любой софт, который умеет забирать данные по ssh. Как я уже сказал rsync, unison, Butterfly Backup, rsnapshot, ElkarBackup, BackupPC, Burp и т.д.

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

Для первой схемы есть возможность себя обезопасить. Например, можно использовать в качестве хранилища S3. В правах доступа к бакету запретить возможность удаления данных. А чтобы обеспечить ротацию архивов, настроить политику удаления старых данных средствами хранилища S3. Я активно применяю такую схему. Делаю 3 бакета: day, week, month. В первом данные хранятся 7 дней, во втором 4 недели, в третьем вечно. Получается дёшево и безопасно.

Более масштабные системы типа Veeam, PBS, Vinchin и т.д. используют оба метода - там и центральный сервер с политиками хранения, и агенты на хостах. Компрометация хостов с агентами не ведёт к потере резервных копий. Разумеется, если в самой серверной части нет уязвимостей. А они иногда бывают. В этом плане вторая схема со скрытием от посторонних глаз сервера с бэкапами наиболее безопасная.

#backup