cranequinier: (65x70)
[personal profile] cranequinier

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

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

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

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

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

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

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

Date: 2015-12-04 04:25 am (UTC)
From: [identity profile] alextutubalin.livejournal.com
Бэкапить работающий диск конечно можно, иначе весь мир сидел бы без бэкапов.
В моем линуксе (который называется FreeBSD) для "бэкапа работающего диска" у dump есть ключик L

Базу так бэкапить, по идее, тоже можно (оно ж транзакционное и должно недозапись при аварии переживать), но я так никогда не делал и бэкапил базы штатными средствами. У моего MySQL (который называется PostgreSQL) есть специальная утилита pg_dump для этого.

Date: 2015-12-04 05:26 am (UTC)
From: [identity profile] anspa.livejournal.com
Базы редко когда такое издевательство переживают. Это ж не внезапное выключение питания, против которого транзакционный механизм работает более-менее (и то совершенно не всегда), а последовательная считка секторов файловой системы в то время как база себе думает здесь пишем, два в уме, а потом туда куда уже рыбу заворачивали и оно считалось - еще раз пишет что-то совсем не целостное. Впрочем, в моем MySQL (который называется MyISAM) такой финт проходит безболезненно, там все еще локи на уровне таблиц и транзакций практически нет.

Date: 2015-12-04 05:34 am (UTC)
From: [identity profile] cranequinier.livejournal.com
> последовательная считка секторов файловой системы в то время как база себе думает здесь пишем, два в уме

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

Date: 2015-12-04 05:52 am (UTC)
From: [identity profile] anspa.livejournal.com
А у меня, кхм, вместо ощущения немножко опыт. =) Innodb, SQL server и Oracle такое совсем не любят и беспечно накрываются ЖПО. Про PostgresSQL не знаю, не приходилось его так мучить.
Edited Date: 2015-12-04 05:57 am (UTC)

mysqlhotcopy

Date: 2015-12-04 07:23 am (UTC)
From: [identity profile] freedom_of_sea.livejournal.com
говорит базе что сейчас будет копировать её файлы

Date: 2015-12-04 06:27 am (UTC)
From: [identity profile] alextutubalin.livejournal.com
Базы с транзакциями вообще должны такое переживать: восстанавливаем на какой-то консистентный чекпоинт и сверху журнал транзакций накатываем. Другой вопрос, что это не обязательно штатная процедура запуска.
Надо у специалистов спросить про постгрес, но вот из общих соображений - оно должно работать (в постгресе опять же версионность и какую-то версию, по идее, можно вытащить "транзакционно целую" и уже от нее накатывать лог).

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

Date: 2015-12-04 06:38 am (UTC)
From: [identity profile] anspa.livejournal.com
Тогда это уже не штатно переживать, а как-то вручную и с плясками с бубном. Это уже потребует вмешательства человека сеньйор-дба, потому как разные датафайлы будут просто принадлежать разным версиям. Как и логи и лог логов. И решиться куда откатываться ни база сама не сможет, ни джуниор дба. Да, в таком случае приходится откатываться назад, а потом еще и накатывать транзакции выборочно, потому что там к примеру чарджи на клиентские кредитки, которые уже в виде живых денег сняты или не сняты, по определенным причинам. Но это уже не про обсуждаемый сетап. Моя же мысль была такая - снимать такой бэкап в котором неизвестно что пропадет или не пропадет, и по которому база потом просто может не запуститься, довольно бессмысленное занятие.

Date: 2015-12-04 07:29 am (UTC)
From: [identity profile] alextutubalin.livejournal.com
Почему выборочно то накатывать?
Все что лежит в transaction log - НУЖНО накатывать. Потому что всему миру уже сказали, что вот транзакция прошла (деньги списаны и проч).

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

Date: 2015-12-04 07:53 am (UTC)
From: [identity profile] anspa.livejournal.com
Это если живой транзакционный лог по крайней мере не старее файлов данных, а если он испорчен (нули вместо контента записаны) либо считывался в бэкап раньше а потом произошло отключение (или закончился бэкап). Если даже штатно остановить базу в какой-то момент, то там будут ситуации а) подтверждения от credit card processing вообще не дошло до базы, а деньги с карты сняты б) подтверждение было получено, но потеряно потому что база была выключена, пришел момент X - т.е. эта транзакция относительно базы неуспешная, а относительно credit card processing - совершившаяся в) комбинация нескольких таких прошедших операций относительно одного и того же клиента.

Date: 2015-12-04 08:05 am (UTC)
From: [identity profile] alextutubalin.livejournal.com
Вы говорите не о базе, а о бизнес-логике распределенного (потому что внешний процессинг) приложения.

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

Date: 2015-12-04 08:14 am (UTC)
From: [identity profile] anspa.livejournal.com
Я говорю о том с чем приходится иметь дело DBA когда уронена production база. Конечно, уронена может быть по-разному.

Date: 2015-12-04 06:45 am (UTC)
From: [identity profile] bowhill.livejournal.com
Ну, на vps блокового доступа скорее всего не будет. Так что базу и подобное отдельно, конфигурации отдельно, метаданные, ссылки и т.д.

Date: 2015-12-04 07:24 am (UTC)
From: [identity profile] alextutubalin.livejournal.com
А, ну да, на виртуалке хуже.

Никогда не имел дела с VPS.
Edited Date: 2015-12-04 07:26 am (UTC)

Date: 2015-12-04 02:59 pm (UTC)
From: [identity profile] bowhill.livejournal.com
Это да, конечно, только бюджеты качественно разные.

Date: 2015-12-04 03:06 pm (UTC)
From: [identity profile] alextutubalin.livejournal.com
Вполне вменяемые (для каких-то целей, вроде десятка мелких сайтов) физические сервера начинаются с 10 евро в месяц.

По мне, и 5 (за виртуалку) и 10 - это никакая не качественная разница, а все какие-то слабоотличимые от нуля деньги.

Date: 2015-12-04 03:20 pm (UTC)
From: [identity profile] cranequinier.livejournal.com
> Вполне вменяемые (для каких-то целей, вроде десятка мелких сайтов) физические сервера начинаются с 10 евро в месяц.

Для десятка мелких файлов можно и shared hosting завести.

А вот для CPU круче чем 4 коры 2.4 GHz за $15 на RamNode я ничего не нашел.

> По мне, и 5 (за виртуалку) и 10 - это никакая не качественная разница, а все какие-то слабоотличимые от нуля деньги.

10 за Атом это деньги на ветер. Ну, в меру моего понимания что такое Атом.

Date: 2015-12-04 03:53 pm (UTC)
From: [identity profile] alextutubalin.livejournal.com
А что происходит, если ты эти 4 коры грузишь на 100% в течение недели?

Date: 2015-12-04 04:04 pm (UTC)
From: [identity profile] cranequinier.livejournal.com
Я начинаю заботиться о яхте в Карибском море и нанимаю каких-нибудь других людей чтобы они мне заботились о хостинге.

Date: 2015-12-04 04:10 pm (UTC)
From: [identity profile] alextutubalin.livejournal.com
Или ты начинаешь искать другой хостинг?

Date: 2015-12-04 05:31 pm (UTC)
From: [identity profile] cranequinier.livejournal.com
Если мне неделю забивают четыре коры, то вполне возможно что новый хостиг уже ищу не я.

А я такой с мохитой в Карибском море.

(no subject)

From: [identity profile] alextutubalin.livejournal.com - Date: 2015-12-04 05:44 pm (UTC) - Expand

(no subject)

From: [identity profile] cranequinier.livejournal.com - Date: 2015-12-04 05:54 pm (UTC) - Expand

(no subject)

From: [identity profile] bowhill.livejournal.com - Date: 2015-12-05 11:52 am (UTC) - Expand

(no subject)

From: [identity profile] alextutubalin.livejournal.com - Date: 2015-12-05 02:41 pm (UTC) - Expand

(no subject)

From: [identity profile] bowhill.livejournal.com - Date: 2015-12-05 04:29 pm (UTC) - Expand

(no subject)

From: [identity profile] alextutubalin.livejournal.com - Date: 2015-12-05 04:37 pm (UTC) - Expand

(no subject)

From: [identity profile] alextutubalin.livejournal.com - Date: 2015-12-05 04:43 pm (UTC) - Expand

(no subject)

From: [identity profile] bowhill.livejournal.com - Date: 2015-12-06 08:04 am (UTC) - Expand

(no subject)

From: [identity profile] cranequinier.livejournal.com - Date: 2015-12-07 03:06 am (UTC) - Expand

(no subject)

From: [identity profile] bowhill.livejournal.com - Date: 2015-12-06 07:51 am (UTC) - Expand

(no subject)

From: [identity profile] alextutubalin.livejournal.com - Date: 2015-12-06 08:12 am (UTC) - Expand

(no subject)

From: [identity profile] bowhill.livejournal.com - Date: 2015-12-06 08:37 am (UTC) - Expand

Date: 2015-12-04 03:33 pm (UTC)
From: [identity profile] bowhill.livejournal.com
Это ты знаешь очень грибные места или сервер -- одноплатка за $75 с SD.

Date: 2015-12-04 03:47 pm (UTC)
From: [identity profile] alextutubalin.livejournal.com
Эти "грибные места" - это крупнейший хостер в мире OVH.
В том своем лице, которое называется kimsufi

Date: 2015-12-05 10:38 am (UTC)
From: [identity profile] bowhill.livejournal.com
Спасибо, интересно. Хотя, и под свой класс задач (кстати, это они в РФ почти не продают?)

Вот ещё о чём подумал, ну с окупаемостью железа: предположим б/у треш, сопоставление с ценами на юнит -- тоже можно что-то придумать, но просто электричество.

Во Франции это ~0.12 €/kWh (если не путаю), в Германии дороже, ~0.24 (привет, Hetzner). Ну ладно, атомы в блейдах, ватт по 20, в месяц съедят на €2 во Франции и €4 в Германии. Но если сервер кушает хотя бы 100 ватт -- это уже другие деньги, €10 и €20. Где профит? Возможно в том, что ты в итоге перейдёшь с убыточного промо на нормальный тариф.

Date: 2015-12-05 02:58 pm (UTC)
From: [identity profile] alextutubalin.livejournal.com
У OVH европейский ДЦ во Франции. И там может быть какое-нибудь послабление по тарифу для датацентров (если, к примеру, ты строишь прямо на АЭС).
У Kimsufi железо, очевидно, ворованое из музея. Атомы - еще свежие (2011), а вот i7-920 - это ж вообще 2008-й год примерно.

Но с потреблением ты скорее всего завысил. Atom этот - 6.5 ватт (это типа при загрузке), то есть на сервер скорее 10, если не меньше.

i7-920 - да, там TDP 130W (с диском и охлаждением в пике - все 150), но среднее то будет 50, никак не 100.

Date: 2015-12-05 04:45 pm (UTC)
From: [identity profile] bowhill.livejournal.com
Это я посмотрел тарифы для крупных потребителей (я тоже хитрый), Атом сам может и мало ест, но там ещё и матплата есть, память, диски.

По обычным серверам, я не думаю, что потребление будет пиковым, но плавно и лениво обмахиваться ушами такой сервер тоже вряд-ли будет.

Я вот только не понял, у Kimsufi есть ipv4? Может это всё же просто promo [joint]? Какие-то разумные цены начинают начинаться у SyS.

(no subject)

From: [identity profile] alextutubalin.livejournal.com - Date: 2015-12-05 04:52 pm (UTC) - Expand

Profile

cranequinier: (Default)
cranequinier

March 2020

S M T W T F S
1234567
891011121314
15161718192021
22 232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 10th, 2025 07:49 pm
Powered by Dreamwidth Studios