Какие подводные камни могут быть при шифровании бэкапа сайта и его БД?

Question

[Tech]

Планирую бэкапы изредка складывать в облако яндекса или мэйлру.
Соответственно, предварительно хотелось бы зашифровывать архивы и дампы БД.
Локаль хоста en_US.UTF-8.
Сайт на битре. Кодировка БД utf8mb3/utf8mb4.
Архив сайта производится таром.
Дамп БД выполняется с помощью mysqldump.
Оба локально.
Далее шифрую симметричным шифрованием с паролем.

tar -cvzf - folder_with_WEBSITE_TAR_and_DB_dump | gpg -c > encrypted.tar.gz.gpg

Какие потенциальные проблемы могут быть в данном подходе в процессе шифрования/расшифрования? Например, может ли кодировка кириллицы внутри дампа БД (или текстовых файлов корня сайта) "покоцаться" ?
Или в архиве вдруг есть пути с экранированными спецсимволами и так далее.

Или, например, если расшифровка будет происходить на другом линукс дистрибутиве? Или важна ли версия gpg?

И если да, то какими опциями gpg можно гарантировано получать шифрованный архив, дабы расшифрованный бэкап на любом линуксе был бы точно таким же как и исходный?

Comments

[Дмитрий]

Архивация и шифрование обычно никак не затрагивает данные внутри архива (кодировки, переносы строк и т.д.). И сейчас вместо gzip целесообразнее использовать zstd, упаковывает/распаковывает эффективнее и при этом в разы быстрее. Поддержка zstd в свежих версия tar есть. Из man:
--zstd Filter the archive through zstd(1).

[Ivan Ustûžanin]

а ещё подводные камни могут быть и при экспорте через utf8mb3 при наличии символов из utf8mb4

[Tech]

Ivan Ustûžanin, Это понятно - это уже касается процесса восстановления дампа БД, независимо от gpg. Меня больше интересуют подводные камни шифрования/расшифрования gpg.

[Everything_is_bad]

Tech, шифрования/расшифрования, как и архивация/разархивация не меняет состояние исходного текста, т.е все возможные проблемы с кодировкой точно не от этого процесса будут

[pfg21]

ни локаль машины, ни методы сжатия/шифрации никак не повлияют на данные внутри файла :) это другое.
единственно что повлияет это настройки "конвертора из бд в файл" т.е. mysqldump

[Виктор Таран]

К размышлению добавлю
1. "пароль" в дампе обязательно через eval поскольку в пароль может содержать все нормальные спецсимволы экранирования, реально были прицеденты, тем более если ты в динамике бэкапиш сайты.
2. читай с .settings.php переменные, прям на пхп и юзай их прям в скрипте. очень удобно.
3. Складывай в дамп текущую версию phpinfo, прмям php -i и в файлик, дабы дампы могут быть старые, и одну версию пхп можешь долго впоминать, my.cnf тоже желательно мало ли сколько лет пройдет, но опять же от задачи.
Я себе бэкапил каждый деть /etc поскольку сломать что-то можно а бэкап ничего не весит.
4. Мне нужны были и ключи ssh поскольку при восстановление на новом сервере ты безшовно можешь переписать А запись. А для этого было бы не плохо сразу и ключи иметь, поскольку LE не может их генерировать новые на новом сервее без А записи.
5. mysql очень очень хорош сжимается архиватором. ( до 20 раз) так что архив
6. ВСЕ делать в ПОТОКЕ посколку это очень очень ускоряет работу, не занимает места на диске, и не имеет ни одного и минусов
7. Лог дампов к себе в телегу или в почту, как минимум если дамп завершился с кодом отличным от 0, зачем это, все просто если у тебя innodb полетит то есть шанс что на определенной таблице у тебя будет падать вся msql, просто от show tables; и дальнейший дамп будет делать пустые баыз.
8. Если дамп по какой-то причине поулчился с размером 0 - тоже-самое.
9. ограничивай скорост заливки на резервный сервер, поскольку I-O сервера и канал может сильно просесть.
10.Если битрикс ВМ получай все данные сразу с json виртуальной машины. и пути до сайтов и базы и все вот это, только пирси сразу jq
11. Вот что нашел у себя из старого, может быть полезно, и как минимум оно работает в потоке.

Дамп базы и заливка на дургой сервер в потоке и востановление сразу в бд минуя файлы, архивируя естественно и распаковывая

ТЫЦ

mysqldump -u'userbitrix' -p'BdAz222hrsu5c' dbbitrix | gzip | ssh bitrix@11.12.42.31 -p 22 'gunzip | mysql -u'userbitrix' -p'B22235hrsu5c' dbbitrix'

Перенос сайта в потоке, так же в архиве и распаковываем на новом месет, только добавь в исключение dbconn и вот это все

ТЫЦ

cd /home/bitrix/ext_www/site1.ru; \
 tar -cvpzf - \
 --directory /home/bitrix/ext_www/site1.ru \
 --ignore-failed-read \
 --exclude='./bitrix/tmp' \
 --exclude='./bitrix/backup/*\.gz*' \
 --exclude='./bitrix/backup/*\.tar*' \
 --exclude='./bitrix/cache' \
 --exclude='./bitrix/managed_cache' \
 --exclude='./bitrix/stack_cache' . | ssh bitrix@222.222.222.222 -p 22 "cd /home/bitrix/ext_www/site2.ru.ru;tar xvfz -"

Только новые файлы за последние 2 дня

ТЫЦ

cd /home/bitrix/ext_www/site1.ru; \
find . -type f -mtime -2 \
  -not -path "*/bitrix/managed_cache/*" \
  -not -path "*/bitrix/stack_cache/*" \
  -not -path "*/bitrix/cache/*" \
  -print0 | xargs -0 cp --parents --target-directory=/tmp/test ; tar -cvpzf - --directory /tmp/test  --ignore-failed-read  . | ssh bitrix@11.228.42.72 -p 22 "cd /tmp/test;tar xvfz -" 

cd -

Дамп сразу указываем кодировку (желательно знать точную)

ТЫЦ

mysqldump --default-character-set=utf8mb4

Кодировочка поплыла

ТЫЦ

#!/bin/bash

DB_NAME="dbbitrix"

# Получаем список таблиц
tables=$(mysql  -D"$DB_NAME" -Bse "SHOW TABLES;")

# Применяем ALTER TABLE для каждой таблицы
for table in $tables; do
    echo "Изменение кодировки таблицы: $table"
    mysql -D"$DB_NAME" -e "ALTER TABLE $table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;"
done

echo "Все таблицы обновлены."

[Tech]

Виктор Таран, Спасибо!

[d'Ivan]

Виктор Таран,

mysqldump -u'userbitrix' -p'BdAz222hrsu5c' dbbitrix | gzip | ssh bitrix@11.12.42.31 -p 22 'gunzip | mysql -u'userbitrix' -p'B22235hrsu5c' dbbitrix'

После -p 22 , если не ошибаюсь, проблема с кавычками.

[Виктор Таран]

d'Ivan, не там все нормально у конечной базы тоже нету