Бакуп бч


Бакуп бч
Шпаргалка на память.

Оригиналы block_log block_log.index shared_memory.bin взяты тут:

wget -c --user=u237308-sub1 --password=3oOk8579Ff8ceKdy --tries 100 https://u237308-sub1.your-storagebox.de/block_log
wget -c --user=u237308-sub1 --password=3oOk8579Ff8ceKdy https://u237308-sub1.your-storagebox.de/block_log.index
wget -c --user=u237308-sub1 --password=3oOk8579Ff8ceKdy --tries 100 https://u237308-sub1.your-storagebox.de/shared_memory.bin

По окончанию загрузки wget отрапортует:

‘block_log’ saved [37519427950/37519427950]
‘block_log.index’ saved [387328480/387328480]
‘shared_memory.bin’ saved [8589934592/8589934592]

ls -l
-rw-r--r-- 1 root root 37519427950 июн 2 00:06 block_log
-rw-r--r-- 1 root root 387328480 июн 2 00:06 block_log.index
-rw-r--r-- 1 root root 8589934592 июн 2 00:14 shared_memory.bin

На текущий момент числа естественно будут возможно другие,
кстати числа запомните, пригодятся при восстановительных работах,
пример :

ls -l > size.txt

Запаковка в архив:

В каталоге с блок-логом, шаред-мэмори командуем:

dd if=block_log bs=1M | gzip -c > /home/user/home/blockchain/block_log.dd.gzip
dd if=block_log.index bs=1M | gzip -c > /home/user/home/blockchain/block_log.index.dd.gzip
dd if=shared_memory.bin bs=1M | gzip -c > /home/user/home/blockchain/shared_memory.bin.dd.gzip

Каталог назначения можно другой,
блок_лог сжимается наполовину, шарэд_мэмори больше чем в три-пять раз.

Из соседнего терминала можно командовать:

kill -USR1 $pid_of_dd
где $pid_of_dd - pid dd, можно узнать например так:
top | grep dd
или
ps -A | grep dd

watch -n 15 "kill -USR1 $pid_of_dd"

будет каждые 15 секунд выполнять это действие.
Эти команды позволят наблюдать за процессом.

Полученные архивы переместил в /home/user/home/blockchain/bakup

Распаковка(восстановление) из архива:

Распакуются в текущую, у меня это /home/user/home/blockchain
архив при этом в /home/user/home/blockchain/bakup

cd /home/user/home/blockchain
#rm -f # тут можно удалить старые, поврежденные блок_лог, шаред_мемори
gunzip -c ./bakup/block_log.dd.gzip | dd of=./block_log bs=1M gunzip -c ./bakup/block_log.index.dd.gzip | dd of=./block_log.index bs=1M gunzip -c ./bakup/shared_memory.bin.dd.gzip | dd of=./shared_memory.bin bs=1M`

block_log и block_log.index можно восстановить простым урезанием до начальной длины, информация в них пишется последовательно(однако это лишь мое предположение),
команды простые :

truncate -s 387328480 block_log.index
truncate -s 37519427950 block_log

Эти 3 простые команды(две truncate и однаgunzip ) помогли восстановить на днях работоспособность ноды.Без реплэя.


Comments 18


@id-mine, ну вот, спасибо за полезный пост 👍️

03.07.2021 13:28
0

@id-mine, кстати натолкнул на мысли держать один из бэкапов на серваках уже в сжатом виде, для тех кто не юзает Hetzner (у них то скорость итак приличная, бэкап выкачивается за 10-15 минут).

03.07.2021 13:30
0

@lex, да, там где гигабитные каналы, возня с dd наверное излишня, dd отрабатывает не так уж и быстро

03.07.2021 15:52
0

@lex, анализ файла block_log архиваторами zip и rar показал что объем уменьшится примерно на 30% от оригинала. tar, я думаю, покажет еще хуже потому что его алгоритм архивирования более топорный. А процесс распаковки - это еще нужно дополнительное место на диске для кэша и для размещения результирующего файла. Так вот есть ли смысл вдвое больше переплачивать за дисковое пространство?
Разумеется я об арендованном VPS/VDS, если нода на локальной машине, стоящей у тебя под ногами - то можно и в незапакованном виде хранить, причем сразу в нескольких экземплярах 😊

30.07.2021 12:26
0

@leva64, смысла мало, проверял после того коммента время распаковки при вариантах нормального сжатия +- близко к времени скачивания (на обычных впсках).

Ну а если сервак мощный, на нём скорее держат свой бэкап или канал позволяет тянуть в сыром виде...

30.07.2021 12:32
0

@lex, надеюсь ты не будешь агрится на микроскопический флажок )

01.08.2021 06:56
0

@fotogid, ухх, кто посмел 😂 😂 😂

01.08.2021 12:20
0

@lex, повторял этот рецепт, действительно, жмется процентов на 50
соглашусь при высокой скорости соединения смысла мало, wget отработает может даже быстрее dd
Разве маленько видоизменить рецептик, и хранить(и передавать) кусочками, ну вот как у битка чейн не одним файлом хранится, а мелкими дольками

01.08.2021 07:03
0

@kedgaks, ну или юзать rsync
на всех бэкапах он тоже есть, просто заменять на

rsync --progress -e 'ssh -p23' --recursive u237308-sub1@u237308-sub1.your-storagebox.de:golos/ /root/home/blockchain/
01.08.2021 12:23
0

@leva64,

А процесс распаковки - это еще нужно дополнительное место на диске для кэша и для размещения результирующегфайла.

wget архрхив -> dd -> результат
и место свободно
впрочем все это ерунда, мая возня
забыл: ta не жмет ссамозня

01.08.2021 07:11
0