Pull to refresh

Comments 17

Более половины решений в списке альтернатив restic используют rsync. А вот мы с вами взяли — и использовали его напрямую. We need to go deeper. В следующий раз будем реализовывать rolling hash на голом шелле и netcat.

Можно же проще.
Пример из скрипта.
snapshotdir="`date +\%Y-\%m-\%d\%R`"
mkdir $backup_dir/$snapshot_dir
rsync -avHXE --delete --delete-excluded --exclude-from=$exclude_file --progress --stats --numeric-ids --link-dest=$backup_dir/last $mnt_dir/ $backup_dir/$snapshot_dir/


rm $backup_dir/last
ln -s $backup_dir/$snapshot_dir $backup_dir/last

Можно по-всякому. Можно даже без ln -s, просто искать в $backup_dir последний по дате снапшот с помощью ну скажем find $backup_dir -maxdepth 1 -exec stat -c '%n' {} +|tail -n1 и линковать на него.

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

for file in {0..9}; do echo mv www.$file www.$(($file+1)); done
Ох, какое непреодолимое препятствие.
for file in {0..9}; do echo if [ -d www.$file ]; then mv www.$file www.$(($file+1)); fi; done
А зачем такой огород, если rsync умеет --backup-dir=$(date +%Y%m%d), который держит актуальную копию данных в отдельном каталоге, а изменившиеся (с момента создания предыдущей копии) файлы складывает в другой с сохранением всей иерархии? Т.е. в результате имеем полную копию всего и рядом историю изменений (между копиями) каждого файла. Без всяких скриптов
поправлюсь… не "… изменившиеся файлы складывает...", а старые версии изменившихся файлов кладет рядом, а в основном снапшоте — всегда актуальные файлы.

Так ведь хардлинков нет. Они нужны для того, чтобы внутри каждой из папочек www.0, www.1, www.2 содержимое соответствовало копии на момент копирования. Ну и для дедупликации. Вам же не хочется 10 копий одного и того же файла хранить.

Не нужна дедупликация, т.к. ничего "лишнего" не хранится. Рядом по каталогам рассовываются только изменившиеся файлы. В итоге получается, что есть всегда актуальный спапшот каталога-источника и рядом "история" прошлых версий изменившихся файлов:


main
  folder
    file1
  file2
  file3
20191112
  file2
20191113
  folder  
    file1
  file3

Т.е., чтобы получить данные на какую-то конкретную дату, берется каталог "main" и сверху него кладется с заменой каталог с нужной датой.

т.е. последовательно "отмотать" все даты… что-то я туплю с утра.

вот так я делаю бэкапы.
cp -al делает не копирует файлы, а создает жесткие ссылки на них.
rsync потом копирует и создает только изменившиеся файлы.
В результате получаются директории в которых находятся "снапшоты" копируемой директории.
Если вы копируете какой-нибудь офисный файловый ресурс, то корневую директорию резервных копий можно подключить через плагин теневых копий samba и пользователи будут видеть состояние ресурса на каждый день.


basepath=/path/to/backup
today=`date +%Y%m%d`
yesterday=`date --date=«yesterday» +%Y%m%d`
monthago=`date --date=«30 day ago» +%Y%m%d`

todaydir=$basepath/$today
yesterdaydir=$basepath/$yesterday
monthagodir=$basepath/$monthago

mkdir -p $todaydir

cp -al $yesterdaydir $todaydir

rsync -a --delete /path/to/files/ $todaydir

rm -rf $monthagodir
Т.е. получается если похерился или случайно удалил мастер-бекап, все остальные будут нерабочими?
скорее частично рабочими.
Теже Бакула\Бареос тоже при потере Фулла, по Инкрементам не всегда смогут восстановить актуальную копию.
ЗЫ. хотя были случаи когда с момента создания Фулла все файлы менялись как минимум один раз. В итоге получилось восстановить актуальную копию только по Инкрементам.
При удалении мастер-бекапа как раз ничего страшного не произойдёт. Хардлинки же.
Главное не редактировать эти файлы. И даже права доступа менять не желательно.
Only those users with full accounts are able to leave comments. Log in, please.