Comments 26
21 век на дворе, https://github.com/jimsalterjrs/sanoid/wiki/Syncoid наше все. =)
Через rsync я откатываю особо критичные вещи только с VPS для которых ZFS слишком тяжелая.
В rsync можно ещё добавить --sparse к остальным параметрам, это должно ускорить копирование некоторых файлов, в которых есть нули, эта пустота не будет копироваться.
Возникает вопрос: зачем btrfs? Если не используется резервное копирование средствами этой фс - там вроде можно снимать снапшоты. Ну и вообщем, если бекап rsync'ом, то кроме etc и home больше ничего и не нужно, а если что-то ещё, то проще целиком снапшоты делать
Этак можно использовать любую тулзу для бекапов (например, backintime), просто отформатировать fs под сжатие, чтобы лучше влезало.
Фс со снапшотами для хранения бэкапов не нужна.
Для того, чтобы сделать инкрементный бэкап сначала из вчерашней директории в сегодняшнюю директорию сделайте так:
cp -al yesterday_dir today_dir
Эта команда сделает дерево директорий где вместо файлов - жесткие сссылки.
После этого делайте в today_dir копирование rsync'ом с ключами -a --delete.
rsync заменит измененные файлы новыми версиями разорвав жесткие ссылки или удалит директории или жесткие ссылки на файлы если на источнике для бэкапа они были удалены.
Таким образом в каждой директории будет храниться снапшот директории на время бэкапа и дубли файлов создаваться не будут.
Почему не restic?
У него нормальная реализация инкрементальных бекапов вместо костылей с линками, нормальное сжатие вместо костылей с btrfs.
Нормальный способ указать что папку не надо бекапить (файлы CACHEDIR.TAG).
Urbackup в image режиме - норм, можно оживить полностью убитую вместе с загрузчиком систему. Да и места занимает такой бэкап сравнительно меньше, чем в файловом режиме.
хардлинки — это чтобы изменение 1 байта в гигабайтном файле обнулило весь профит, вместо того, чтобы использовать подход модификации снэпшотов на целевой btrfs, которая в таком случае перепишет только один блок? Вы там патетически просите пожалуйста бэкапы делать — вы пожалуйста прежде, чем писать на тему бэкапов, хотя бы изучите предмет.
Использую borg. Просто работает. Танцев с бубном ненадо.
Похоже, что ваш скрипт сломается, если запустить его из каталога, в пути к которому есть пробелы — переменная p присваивается и всюду подставляется без кавычек.
Не понимаю, по какому принципу вы выбираете, когда поставить кавычки, а когда нет — как по мне, подстановки переменных нужно квотировать тотально, а не выборочно. Также имеет смысл проверять все свои скрипты через ShellCheck.
как по мне, подстановки переменных нужно квотировать тотально, а не выборочно
Бывают случаи, когда лишние кавычки вредят, например
OPTS="-l"
OPTS2=""
OPTS2="-l --sort=none"
ls $OPTS
ls $OPTS2
ls $OPTS3
ls "$OPTS" # работает
ls "$OPTS2" # НЕ работает
ls "$OPTS3" # НЕ работает
я безусловно ставлю в кавычки только те переменные, что содержат имена файлов, в остальных случаях думаю ожидает ли вызываемая программа получить значение переменной, содержащее пробелы, как один аргумент
Если у вас честный баш без требований совместимости с POSIX-шеллом, в этой ситуации очень удобно использовать массивы. Ваш пример я бы написал примерно так:
declare -ra options=(-l --sort=none)
ls "${options[@]}"
Можно и без declare -ra, это моя привычка везде явно ставить declare/local и делать переменные ридонли, если это возможно.
В целом же ситуации, когда нужна подстановка без кавычек и никак иначе, конечно же, встречаются. Имхо, каждую такую ситуацию следует рассматривать как особый случай, объяснить причину в комментарии и отключить для строки диагностику ShellCheck:
# It's not possible to pass arrays via environment. Falling back to a plain string.
# shellcheck disable=SC2086
ls ${MYSCRIPT_LS_OPTIONS:-}
По правде говоря, в статье с заголовком про «бэкап при помощи rsync и Btrfs» ожидал увидеть совершенно другой сетап. Что-то вроде такого:
средствами Btrfs делаем ридонли-снапшоты интересующих сабвольюмов,
затем c этих снапшотов спокойно, не отрываясь от работы делаем rsync-ом хороший, консистентный бэкап на удалённый сервер (или несколько серверов — данные зафиксированы и не изменятся между проходами).
Тут rsync можно заменить на restic и будет вообще хорошо: дедупликация, сжатия, шифрование из коробки. Плюс нативная поддержка S3 и Backblaze (и многих других облачных провайдеров — посредством rclone).
Я уже лет 20 делаю резервные копии DAR, и пока не вижу причин от него отказываться.
Раз в месяц полное резервное копирование. Например:
#!/bin/bash
DIR=/media/ptr/SSSS/BACKUP/DAR
FILE=${DIR}/`/bin/date -I`_home_full
/usr/local/bin/dar -z -G 6 -R /home/ptr -c $FILE -Z "*.mp4" -Z "*.wmv" -Z "*.gz" -Z "*.bz2" -Z "*.zip" -Z "*.png" -Z "*.jpg" -Z "*.jpeg" -Z "*.deb"
Каждый день инкрементальное:
#!/bin/bash
DIR=/media/ptr/SSSS/BACKUP/DAR
FILE=${DIR}/`/bin/date -I`_home_diff
PREV=`/bin/ls -tr $DIR/*_home_*.*.dar|/usr/bin/tail -n 1`
/usr/local/bin/dar -z -G 6 -R /home/ptr -c $FILE -Z "*.mp4" -Z "*.wmv" -Z "*.gz" -Z "*.bz2" -Z "*.zip" -Z "*.png" -Z "*.jpg" -Z "*.jpeg" -Z "*.deb" -A ${PREV%%.*}
Не слушайте тех зануд выше, каждый линуксоид должен написать свой скрипт инкрементального бэкапа на rsync.
https://github.com/ei-grad/trinkup
Как я делаю бекапы домашней системы Linux: простой пример инкрементального rsync + btrfs с zstd сжатием