Хотел задать вопрос более опытным форумчанам по данной теме. Приведу пример. Цель создания бэкапов - создать резервную копию данных на случай, если накроется HDD, нужные файлы будут удалены или испорчены. Допустим, у меня создается по расписанию бэкап какой-то папки со 100 файлами. ПО каждый раз бодро рапортует, что бэкап был успешно сделан и я могу быть спокоен. Какое ПО для бэкапов может помимо этого формировать какой-то наглядный отчет, где будет указано, какие-файлы в этой папке со времени прошлого бэкапа были созданы, изменены, удалены. И желательно, чтобы можно было гибко настроить (допустим на основании типа или расширения файлов) какие-то бросающиеся в глаз алярмы. Например, чтобы можно было указать, что если в данной папке существующие .txt файлы были изменены, то проинформировать какие именно и вывести прошлые и нынешние дату/время изменения, размер.
Поясню свою цель. Толку то мне, что просто ежедневно создается бэкап этой папки. Может в ней по моей ошибке был удален нужный файл или, например, шифровальщик все файлы зашифровал. А у меня будут отчеты, что бэкапы делаются и все хорошо. И потом при ротации старые бэкапы с нужными мне данными будут благополучно удалены.
Это уже ближе к какому-то по для аудита, не бэкапилка, а ПО для проверки целостности системы.
Как вариант, можно собрать на основе инкрементальных бэкапов при помощи tar
Либо анализировать borg бэкапы
Я полагаю, что описанные мной возможности чем-то напоминают систему контроля версий. Может какое-то ПО из этой области для моей задачи в дополнение к бэкапилке можно использовать? Это как некоторые предлагают в качестве системы синхронизации файлов использовать какой-нибудь GitHub или аналог (в т.ч. и selfhosted). Тут тебе и синхронизация, и версии файлов и бэкап за их счет.
Расскажу свой опыт. Не претендую на истину. У меня следующая схема
- Syncthing синхронизирует односторонне данные у устройств на сервер
- На севере установлен диск с BTRFS
- Каждый день Snapper делает снимок
Задача была следующая: избежать излишнего усложнения за счёт отдельного NAS (мне проще в консоли сделать), но при этом сохранить версионирование. А Syncthing удобен для кроссплатформенности
В Snapper можно удобно смотреть разницу между снимками. Ну правда тут консоль. Каждому свое
Чуть позже в эту схему добавлю Rclone для бекапа критически важных данных в зашифрованном виде в облака. У меня таких данных не сильно много
Ну и раз в месяц делаю бекап на отдельный диск
Тема перемещена в созданный раздел Бэкапы (резервное копирование).
Спасибо @admin 'у за созданные категорию и тэг. Я вступительное слово из первого сообщения убрал и более осмысленно тему переназвал, раз она теперь в своей категории. Так правильно делать?
Еще хотел бы дополнить свои вопросы одним нюансом, который пока мне не совсем понятен. Если бэкапы делаются с какой-то файловой системы, например, ext4 или ntfs, и перед следующим бэкапом я файлы изменять не буду, но ФС как-то повредится, то в общем случае файлы будут забекаплены (которые не пропадут и не переименуются), но их содержимое будет отличаться? Т.е. при помощи мониторинга я увижу, что такие-то файлы изменились, хотя по идее не должны были? При бэкаплении файлов с ZFS при повреждении ФС (например, RAM без ECC) картина будет та же? Пока такого печального опыта нет, но хотелось бы заранее подстелить соломки.
Да, порча подразумевает чтение неожидаемых данных
Собственно memtest или hddtest записал
f0f0f0, прочиталf0f0da- ошибка
Например, в PBS есть процесс валидации архива, когда он читает файлы и сверяет с контрольными суммами
Валидирует после создания бэкапа и раз в 30 дней потом
Да, но либо в ручном режиме, либо автоматом, но реально надо делать систему аудита, с другой стороны, а смысл бэкапить и что-то там делать?
Соберите локально контрольные суммы с файлов и потом по крону проверяйте их
/tmp/1 ⌚ 16:30:20
$ mkdir files
/tmp/1 ⌚ 16:30:26
$ date > files/file1.txt
/tmp/1 ⌚ 16:30:47
$ date > files/file2.txt
/tmp/1 ⌚ 16:30:51
$ sha256sum files/* > checksums.sha256
/tmp/1 ⌚ 16:31:14
$ sha256sum -c checksums.sha256
files/file1.txt: OK
files/file2.txt: OK
/tmp/1 ⌚ 16:31:30
$ date > files/file1.txt
/tmp/1 ⌚ 16:31:48
$ sha256sum -c checksums.sha256
files/file1.txt: FAILED
files/file2.txt: OK
sha256sum: WARNING: 1 computed checksum did NOT match
Но тут есть момент, что файл мог поменяться специально, тогда можно отталкиваться от метаданных файла
или иcпользовать aide
sudo apt install aide
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check
Вывод: проще разделить эти 2 задачи на две и использовать специализированный софт для каждой из задач по отдельности
Тут проверяется, что не испорчены сами уже хранящиеся файлы бэкапа. С этим более-менее понятно. PBS, NAS’ы от Synology и т.д. это делают. А меня интересует, как предотвратить/обнаружить бессмысленное резервное копирование испорченных файлов и затирание ими годных бэкапов. Вы правильно дальше называете это предварительным аудитом файлов. Надо будет эту aide поизучать. Спасибо.
Но технически это задача 1 в 1, как Вы описываете: храним контрольные суммы файлов и периодически сверяем их с реальными файлами, если файл изменился, то контрольные суммы не совпадут.
Я приводил пример с sha256sum как это работает.
Собственно, в рамках системы мы можем использовать по для проверки целостности системы.
Тут именно изменение файла на диске является побочным продуктом, изначально данное ПО разрабатывается для защиты от взлома системы, например, есть для защиты от руткитов
А та же AIDE
имеет описание
Advanced Intrusion Detection Environment (AIDE) is a utility that creates a database of files on the system, and then uses that database to ensure file integrity and detect system intrusions.
По “backup with integrity checking sftware” гуглится:
Но что-то мне подсказывает, что из бесплатного/опенсорсного ПО проще будет найти отдельно бекапилку и отдельно проверялку (та же aide есть в репозиториях)
@KRom а как у вас организованы бекапы?
Так я и не спорю против того, чтобы 2 задачи, хоть и связанные одной целью, выполняли 2 разных утилиты: одна занималось аудитом, а другая делала бэкапы. Linux way. Спасибо за подсказки, что можно поизучать для этой цели. Теперь есть что почитать, проанализировать и попробовать реализовать.
1. Корпоративные
- локально
- в S3 бакет
- где-то rsync
2. Дома уже рассказывал и тут и в телеграмме
На самом деле у меня в зачаточном состоянии они и далеки от идеала!
- На хостах PBS клиент, например /etc/ и /home бэкапятся каждые 6 часов, подумываю над чаще сделать
- В PVE контейнеры и виртуалки бэкапятся в PBS каждые сутки
- В сервисах пользовательские файлы бэкапятся в PBS каждые сутки, но местами думаю чаще сделать. Это в дополнение к 3 пункту т.е. восстановить можно или контейнер целиком или файлы волюмов
- Руками делаю бэкапы контейнеров локально или на NAS, в целом, подумываю над тем, чтобы хранить 1 резервную копию на холодном носителе
- Одно время конфиги микротика скидывал на git, но сейчас сломалось, надо перенести на новую лабу
- Одно время настраивал time machine4. для макбука на сервер, но тогда были проблемы с местом и отключил т.к. очень много весили бэкапы
В TrueNAS (если из него идет проброс в сервис, например, фотки в immich)
- Ну понятно, RAID массив для надежности
- От потери данных создаются снимки ZFS
- Некоторые каталоги заливаются в облако (у меня сейчас яндекс, но в телеге подсказывали mail.ru диск, он дешевле, но прямой интеграции в truenas нет, можно попробовать через webdav подключить
- Некоторые файлы через rsync периодически заливаются на холодный диск (сейчас руками, но планирую взять свободный USB HDD бокс, впаять туда управление кнопкой питания (вроде на форуме было обсуждение, но я думал по USB сделать) и включать по расписанию диск, подключенный к минику, заливать файлы, а потом отключать его
- Некоторые файлы скопировал на разные пулы, например, у меня под медиа контент 1 диск без резервирования т.к. потеря торрентов не столь болезненна, как потеря фоток. А вот редкие видеофайлы (жена мюзиклы французские собирала много лет) продублированны на другом пуле.
Над чем подумываю еще
- Полный бэкап системы на уровне диска, типа, чтобы можно было вставить новый SSDшник и накатить на него образ системы и в путь. В рабочую систему можно уже актуальные версии подтянуть из 1 пункта
- Поскольку, использую IaC подход, то ативно юзается гит. Планирую сделать зеркалирование на облачный гитлаб или подобный сервис.
Для гитлаба я воообще в свое время писал python скрипт, который проходится по всем репозиториям, скачивает локально, потом заливает на удаленный гитлаб и настраивает зеркалирование репозиториев на удаленный сервер. Надо адаптировать этот скрипт для forgejo - Думал сделать отправку PBS бэкапов на удаленный сервер, одно время Tuxis давали бесплатно 100ГБ облако, можно было нарегать аккаунтов и настроить выборочную репликацию бэкапов, но потом прикрыли лавочку. Пока думаю или через s3 или какой-то PBS поднять на удаленном сервере
Еще мысли
- Одно время пользовал borgbackup, с borgwarehouse, и даже пользовал параллельно с PBS, но потом ушел полностью в сторону PBS
1.1. работает достаточно быстро
1.2. borgwarehouse умеет слать алерты если бэкапы не появлялись какое-то время
1.3 клиент vorta умеет сравнивать бэкапы между собой (прям показывает какие файлы поменялись, какие добавились в каждом бэкапе), можно монтировать бэкап - PBS по-умолчанию, читает все файлы и проверяет контрольные суммы, но это выдает большую нагрузку, я включил режим проверки метаданных, т.е. если файл не поменял размер или дату изменения, то он пропускается, работает очень быстро
- Написал скрипт для удобной настройки бэкапирования файлов
- Использую docker образ proxmox-backup-client для добавления его в docker compose, но он не обновляется и кривоватый, планирую свой проект выпустить с правильной реализацией этого клиента (оттестировал уже на certbot сервисе на основе lego)
- Ну и как заметили уже, использую PBS по полной для бэкапирования
5.1. Виртуалок и контейнеров
5.2. Файлов с хостов
5.3. Docker volume
В общем, особо хвастаться нечем, есть еще над чем работать, но “вы спрашивали, мы отвечаем”
Что-то как-то сложно. Можно проще.
- Хранить данные на томе с проверкой контрольных сумм (ReFS/ZFS). Если посыпется носитель - система уведомит, как минимум не даст прочитать битый файлик.
- Делать инкрементные бекапы, автоматом чекать, если размер критично отличается - аларм выдавать.
- Делать полную копию допустим раз в месяц, проверять ручками, всё ли хорошо.
- Хранить бекапы на той же ZFS, делать снимки, если и словите шифровальщика - вытащите из снимков данные.
- Удалили файлик/посыпался диск на ценной фотке - вытащить с бекапа, то есть полных копий должно быть больше одной. Паранойю можно притушить денежкой на накопители информации.
- Посмотрите на Syncthing, там версионирование есть. Данные сливать им на сервер, там бекапить и прочие обработки крутить.
Я тут читал одну статейку на хабре про безопасность VDS и там попался вот такой инструмент:
AIDE (Advanced Intrusion Detection Environment) — это система контроля целостности файлов, создающая криптографический «отпечаток» состояния системы. Она позволяет обнаруживать несанкционированные изменения: подмену или модификацию системных файлов, внедрение вредоносных программ и попытки скрытия следов атак.
Она создаёт базу с отпечатками файлов и мониторит изменения этих файлов. В том числе удаление. Я подумал, что может помочь.