![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagner) wrote2025-04-13 10:55 am
И еще о бекапах
Надо придумать более гибкую схему бекапа своей VPS.
До сих пор она у меня бэкапилась так - четыре раза в сутки просто rsync-алась файловая система VPS с неким каталогом на десктопе. А дальше уже на внешние диски бэкапился десктоп, rsnapshot-ом в три уровня как положено. Не каждый день, правда, но достаточно регулярно.
Засада в том, что эта схема не работает, когда десктоп выключен (или неисправен). А за последние годы, с начала пандемии ковида это случается регулярно. Уезжаю в деревню, обесточиваю квартиру и все. Некому четыре раза в сутки скачивать с VPS изменения.
Видимо, нужна схема, позволяющая бэкапить VPS сразу на внешний диск. Ппичем чтобы конфиг при этом на внешнем диске и лежал, т.е. при втыкании этого диска в любой из ноутбуков можно было забэкапить не только ноутбук, но и VPS-ку. Объемы изменений там довольно маленькие, по 4G должно справляться.
Правда там еще с ключами разобраться придется. С какими именно ключами ssh пускают на vps рутом чтобы можно было rsync-ать файловую систему. Сейчас из доступных мест эти ключи есть только на бэкапах десктопа.
X-Post to LJ
no subject
Если не секрет, а входит ли в модель угроз ситуация заражения одного или нескольких устройств? С точки зрения нераспространения заражения через используемый для бэкапов внешний диск.
no subject
Распространение заражения через внешний диск - не входит. Заражение само по себе не распространяется, оно требует запуска каких-то зараженных файлов. С внешнего диска ничего не запускается.
Так что в с случае заражения придется просто восстанавливатся не с последнего бэкапа, а с последнего заведомо незараженного. Благо на этом диске там хранится семь дневных, четыре недельных и четыре месячных.
no subject
no subject
Думал. Пришел к выводу что это хуже. На роутере то openwrt, к тому же допоптопный, 19-й. Пытался тут до 21.19 сапгрейдить, а он говорит, мол железка не соответствует. Старый из какой-то неофициальной сборки стоял, а новый вроде уже в мейнлайне этот роутер поддерживает, но что-то там идентификаторы железа разные получились. В общем не рискнул пока.
Для того чтобы перенести на роутер систему бэкапа, туда нужно перл вкрутить. Поскольку rsnapshot на перле написан. И rsync, и openssh полноценный вместо dropbear. Потому что этот dropbear никто на vps не пустит, он алгоритмов современных не знает. А там 3Мб свободного места всего.
Опять же usb-hdd, прикурченный к постоянно включенному роутеру будет постоянно под током. В отличие от внешних дисков, которые большую часть времени проводят в ящике стола, ни к чему не подключенному.
Ну и еще бэкап у нас делается для того, чтобы в случае чего с него восстановиться. Если у меня диск с бэкаопм в рюкзаке, я это могу сделать в любой момент. А если в запертой квартире в нескольких сотнях километров от моего физического места нахождения, это уже сложнее. Тем более что надо IP провайдер выдает динамический и даже по ipv6 попадание на этот роутер при не работающей VPS не гарантировано - это надо чтобы его свежий адрест успел не только в dyndns прописаться. но и оттрансфериться на вторичник до того как VPS упала.
no subject
no subject
Ну вводим зависимость от какого-то внешнего, неподконтрольного мне сервиса.
Так-то у меня все работает через мою VPS. Но тут по условию задачи - восстановление этой VPS из бэкапа, она не работает.
К тому же есть еще одна засада - как пишут на сайте openwrt, большинстов роутеров не тянет внешний USB-диск по питаниюю Свои я еще не проверял на эту тему.
no subject
no subject
Какую пару? У роутера только один USB-слот. USB-адаптеров на два NVME я вноде в продаже не видел. И вообще по-моему NVME более прожорливы по питанию чем диски 2.5"SATA SSD - те точно более прожорливы чем 2.5"SATA HDD. Тем более если их два.
И вообще мы тут обсуждаем систему, которая должна месяцами работать без человеческого пригляда в запертой квартире. Очевидно, конструкция из палочек и бечеовочек для этого не вариант.
Прикрунчивание диска к роутеру имеет смысл для задач. которые треубюут круглосуточной работы при условии наличия в квартире людей, например торрент клиент туда ываихнуть неплохо.
Но это нужен роутер с 128-256Мб памяти.
no subject
Кстати, его можно запускать из chroot на том жэ диске. И не только его -- диски-то у нас сравнительно беспредельные...
2) На самом деле -- можно подрубить нужную директорию через sshfs к какой-нибудь другой виртуалке.
3) Кто это не пустит dropbear? Это ж твой vps!
4) Внешний жёсткий диск в рюкзаке, который все кому не лень пинают и трясут -- это куда более стрёмно, чем внешний жёсткий диск постоянно под током.
5) С одной стороны что он не с тобой -- это несколько неприятно. С другой -- делай два бэкапа...
6) А про IP -- а ты ещё не пробросил обфусцырованный (cloak/vless) VPN (openvpn/amnesiawg/l2tp) между каждой своей vps и каждой точкой доступа? Зря-зря-зря...
no subject
Как-то много сущностей без необходимости. Диски у нас сравнительно беспределные, но не слишком надежные. Когда сдожнет, нужно будет оперативно поменять. Кто не пустит dropbear - я и не пущу. Мне нафиг не надо несекьюррных алогоритмов на моей vps, на нее и так бывает ломятся всяыкие, что очередь MaxStartups переплоняется. Я все-таки не настолько номад, чтобы непрерывно перемещаться по планете с рюкзоакоа. Приехал в деревню, положил диски из рюкзака в ящик стола. Собрался из деревни куда-нибудь в Пеитер, взял с собой. Приехал туда. вселился в гостиницу, положил в тумбочку. Еще раз - мы собираеся бэкапитьту самую VPS. Соответственно в тот моент когда нам понадобилось с этого бэкапа восстанавилваться, VPS не работает и VPN endpoint на ней - тоже.
no subject
no subject
Бэкап может быть заражен. Если заражена машина с которой он делался. Но он не может заразить машину на которую он делается. Потому что в ходе бэкапа ничего копируемого не запускается. То есть нужен как минимум arbitrary code execution в rsync. А Энди Тридгеллу я доверяю. Он такого не напишет.
В принципе, конечно, интересно было бы к процедуре бэкапа приделать проверку какие файлы изменяимь (путем сравнения с предыдущим бэкапом) и сопоставления их списка с установленными апдейтами. с момента прошлого бэкапа (благо /var/lib/dpkg/status тоже бэкапится). Тогда несанкционированные изменения исполняемых файлов можно будет отслеживать прямо в ходе бэкапа.
Я такое люблю - ловить вредоносный код не на той системе, куда он, как он думал, успешно внедрился. На всякий случай тогда бэкап надо на raspberry pi делать, чтобы там бинарный код для x86_64 в принципе выполниться не мог.
no subject
no subject
Нужно очень щелкать клювом, чтобы не заметить трояна прежде чем он успеет познакомиться со всеми сменгыми бэкапными носителями. И нужен очень продвинутый троян, чтобы заразил все версии, срхраненные на одном носителе. Но даже если такое случится - понятно что делать - все переставляем из заведомо чистых (подписанных) пакетов дистрибутива, а с бэкапа восстанавливаем только данные и файлы конфигурации. Если было что саое испоняемое - пересобираем из исходников. Получается в 3-4 реза дольше, чем просто накатить бэкап, но подъемно.