Красноглазики наносят ответный удар, или унесенные Xvfb

[cranequinier]

Чё-то засосало меня в Linux. Варез заработал в Wine под Xvfb (спасибо Тутубалину), и теперь DigitalOcean, MobaXterm и Midnight Commander с чОрным скином высасывают из меня время в бесконечных количествах. Линукс на сервере такая игрушка, просто ми-ми-ми, невозможно оторваться.

А винды на сервере сосут большое время.

Однако остался один вопрос - не могу для себя решить...

Хочу сделать инкрементальный (а в идеале - ещё и с версиями) бэкап пару раз в сутки в какое-нибудь бесплатное место в Сети. Пока нашел для себя Google Drive с 15-тью гигами нахаляву и rclone, который якобы умеет на него синкится. И вроде Google Drive сохраняет версии файлов, так что всё вроде очень круто. В сочетании с бесплатным snapshot от DigitalOcean-а в качестве базового состояния должно хватить.

Но вот в это как-то нет уверенности. Файрволльный скрипт из трёх строчек дла ufw написал, без GUI вроде нормально жить, варез летает, но вот бэкапы смущают. Как-то непонятно даже, что бэкапить. Если только базу данных, могут изменения wordpress потеряться. Если всё что только можно - то где остановиться? Нельзя же бэкапить работающий диск. В принципе там два гигабайта, и по размеру бы оно забэкапилось.

И главное кажется что всё это очень через жопы. Всё остальное правильно и хорошо, а вот чтоб одной строчкой инкрементально бэкапить всю VPS почему-то не нашлось решения.

Подскажите личинке красноглазика.

Comments

[anspa.livejournal.com]

Базы редко когда такое издевательство переживают. Это ж не внезапное выключение питания, против которого транзакционный механизм работает более-менее (и то совершенно не всегда), а последовательная считка секторов файловой системы в то время как база себе думает здесь пишем, два в уме, а потом туда куда уже рыбу заворачивали и оно считалось - еще раз пишет что-то совсем не целостное. Впрочем, в моем MySQL (который называется MyISAM) такой финт проходит безболезненно, там все еще локи на уровне таблиц и транзакций практически нет.

[cranequinier.livejournal.com]

> последовательная считка секторов файловой системы в то время как база себе думает здесь пишем, два в уме

Вот у меня тоже такое ощущение. Не очень сильное, но есть.

[anspa.livejournal.com]

А у меня, кхм, вместо ощущения немножко опыт. =) Innodb, SQL server и Oracle такое совсем не любят и беспечно накрываются ЖПО. Про PostgresSQL не знаю, не приходилось его так мучить.

mysqlhotcopy

[freedom_of_sea.livejournal.com]

говорит базе что сейчас будет копировать её файлы

[alextutubalin.livejournal.com]

Базы с транзакциями вообще должны такое переживать: восстанавливаем на какой-то консистентный чекпоинт и сверху журнал транзакций накатываем. Другой вопрос, что это не обязательно штатная процедура запуска.
Надо у специалистов спросить про постгрес, но вот из общих соображений - оно должно работать (в постгресе опять же версионность и какую-то версию, по идее, можно вытащить "транзакционно целую" и уже от нее накатывать лог).

при "внезапном выключении питания" гарантируется (ну, хорошо, обещается) другое: что транзакция, про которую база сказала что она comitted, лежит на диске и никуда оттуда уже не пропадет.

[anspa.livejournal.com]

Тогда это уже не штатно переживать, а как-то вручную и с плясками с бубном. Это уже потребует вмешательства человека сеньйор-дба, потому как разные датафайлы будут просто принадлежать разным версиям. Как и логи и лог логов. И решиться куда откатываться ни база сама не сможет, ни джуниор дба. Да, в таком случае приходится откатываться назад, а потом еще и накатывать транзакции выборочно, потому что там к примеру чарджи на клиентские кредитки, которые уже в виде живых денег сняты или не сняты, по определенным причинам. Но это уже не про обсуждаемый сетап. Моя же мысль была такая - снимать такой бэкап в котором неизвестно что пропадет или не пропадет, и по которому база потом просто может не запуститься, довольно бессмысленное занятие.

[alextutubalin.livejournal.com]

Почему выборочно то накатывать?
Все что лежит в transaction log - НУЖНО накатывать. Потому что всему миру уже сказали, что вот транзакция прошла (деньги списаны и проч).

А запустится ли база - ну стоит проверить. Нормальная база - должна бы. Недо-my-SQL - ну он и сам разваливается, без посторонней помощи.

[anspa.livejournal.com]

Это если живой транзакционный лог по крайней мере не старее файлов данных, а если он испорчен (нули вместо контента записаны) либо считывался в бэкап раньше а потом произошло отключение (или закончился бэкап). Если даже штатно остановить базу в какой-то момент, то там будут ситуации а) подтверждения от credit card processing вообще не дошло до базы, а деньги с карты сняты б) подтверждение было получено, но потеряно потому что база была выключена, пришел момент X - т.е. эта транзакция относительно базы неуспешная, а относительно credit card processing - совершившаяся в) комбинация нескольких таких прошедших операций относительно одного и того же клиента.

[alextutubalin.livejournal.com]

Вы говорите не о базе, а о бизнес-логике распределенного (потому что внешний процессинг) приложения.

В таком широком определении - абстрактное обсуждение не имеет смысла, в отличие от понятной логики (транзакционной) БД, в распределенных приложениях оная логика очень разная бывает.

[anspa.livejournal.com]

Я говорю о том с чем приходится иметь дело DBA когда уронена production база. Конечно, уронена может быть по-разному.