Простой скрипт для инкрементального бекапа директорий

[lolipop]

YET ANOTHER BACKUP script :)

[lolipop]

парсер такой парсер

[Porfel]

Yanbacks =)
Нет, у нас тут все несколько посложнее, это для себя писал =)

[savant]

Как только не изгаляются люди не желая использовать VCS.

[Porfel]

Не VCS а CVS (SVN), и никто не говорит что не использую. Правда для других задач — как бы системы контроля версий несколько для иных целей создавались имхо.

[savant]

VCS — Version Control System — наиболее общее определение для всех систем контроля версий. Это так, для справки.

[Porfel]

Для справки — я в курсе. И в данном контексте rdiff-backup в таком случае является таковой системой, isn't it?)

[willwin]

причем тут vsc, если нужно бекапить файловое хранилище?

[savant]

> в директории с проектом

Не уточнено, что за проект. Я как программист, под проектом подразумеваю толпу исходников, которые лежат в директории.

Если проект- это обработаное видео, то да, другой разговор.

[StopDesign]

Обычно, далеко не весь проект (в программистском смысле) находится под VCS. Например, локальные настройки и файлы, относящиеся к данным.

[d1m]

VCS помог бы, но при условии что у него можно было бы чистить историю как в rdiff-backup:
rdiff-backup --force --remove-older-than 20D /backups

[igorp1024]

А '--exclude-special-files' не синоним для '--exclude-device-files --exclude-fifos --exclude-sockets --exclude-symbolic-links'?

[igorp1024]

Да и симлинки, ИМХО, иногда полезно хранить.

[t0os]

А если хочу бэкапить не одну, а несколько директорий за раз? Делать кучу копий скрипта?

[aig]

я делаю вот так:

скрипт раскладывает по папочкам каждый день изменений в отдельности и держит текущую версию в папке CURRENT. После чего просто по ssh заливаю на сторейдж папочку текущего дня в архиве.

do_rsync()
{
/usr/local/bin/rsync ${OPTIONS} --backup-dir=${DSTDIR}/${INCDIR} ${SRCDIR} ${DSTDIR}/${CURRENT}
}

OPTIONS="--delete-excluded --delete-after --backup -logthvrpF"
INCDIR=`date +%Y-%m-%d`
CURRENT=«current»

SRCDIR="/etc"
DSTDIR="/opt/backup/rsync/etc"
do_rsync

SRCDIR="/home/"
DSTDIR="/opt/backup/rsync/home"
do_rsync

SRCDIR="/opt/www/"
DSTDIR="/usr/var/backup/www"
do_rsync

[ZZZ_Sochi]

Блин, может я придираюсь потому что программист, но передавать функции аргументы через глобальные переменные, это как-то не очень.

[aig]

Согласен. Это просто издержки предыдущей версии скрипта, он раньше был вообще без аргументов.

[ZZZ_Sochi]

Бывает и такое, понимаю.
Вот сейчас сам сижу и переписываю свои бекапные срипты (их не мало и они сложные), чтобы новый админ понял, что там написано и как оно работает. :-)

[Porfel]

for i in `echo $BACKUP_DIR`; do
...
fi
Внутри блок, начинающийся с if [ ! -d $MOUNTPOINT/$BACKUP_DIR ]; then... и заканчавающийся перед ERRORS=…
Внутри блока $BACKUP_DIR на $i поменять, разумеется.

[mechmind]

«grep -vc grep» -> «wc -l»
портабельней будет.

[Porfel]

Да, черт, привык вывод ps парсить, никак от привычки не избавлюсь.

[seriyPS]

Рекомендую Bacula
Ресурсов почти не жрет, кстати. Разобраться в настройке можно побыстрее чем написать «YET ANOTHER BACKUP script».

[Porfel]

Бакула не удобна тем, что на хранилище надо иметь как минимум bacula-sd, я уж не говорю про наличие fd и director'a.
А у меня на VPS память не резиновая.

[seriyPS]

1) ну, могу сказать что все демоны могут находиться даже на одной машине а sd может с таким же успехом складывать архив на удаленную ФС, хотя это извращение конечно и не так безопасно.

2) ресурсов на самом деле потребляет минимум. клиентский fd у меня на VPS кушает ~1.5Мб оперативки

Кстати, вон в комментариях многие жалуются что при смене админа почти всегда приходится менять бекап-скрипты т.к. в чужих никто разобраться не сможет. А бакула промышленное решение, там с этим проблем не должно быть. Если админ бакулу не осилит — в топку такого админа)) Если под себя все делается то этот момент не так актуален конечно.

Хотя в целом конечно по ситуации надо смотреть. Если у вас 1-2 сервера, а то и просто виртуальный хостинг, то можно скриптами отделаться.
Но если что-то посерьезнее — то нужно и решение соответствующее.

[ZZZ_Sochi]

Когда дело касается баша, мне проще самому для своих задач написать, чем разбирать чужие скрипты.
А так да, использую rdiff-backup. И ещё rsync, так как он быстрее синхронизирует дерево, а это важно для соблюдения целостности также бекапящейся базы данных, которая ссылается на файловую.

[evle]

Не так давно выбирал себе что-нибудь для бэкапа, и rsnapshot понравился больше, чем rdiff-backup. Настройка несколько прозрачнее и удобнее. Несколько уровней копий (ежечасные, ежедневные, и т. д.) с независимыми расписаниями, восстановление до любого состояния простым копированием, и работает, как мне показалось, быстрее.

[Pilat]

Всё, что генерирует много файлов, плохо для хранения бэкапа на внешнем сервере. Как, например, эти файлы перенести на FTP сервер? Никак, очень будет медленно. Восстановление пофайловое с внешнего сервера тоже небыстрое.
Самый простой способ — основывать бэкапную систему не на rdiff-backup, а на dar, конечным продуктом будет один файл на первую копию (full) и по одному файлу на инкрементальные. В качестве обвязки можно использовать www.backup-manager.org/. Кстати, в случае с dar инкрементальную копию можно получить, не храня на компьютере full копию, можно хранить только метаинформацию от неё.

[Porfel]

Спасибо, возьму на заметку.

[rPman]

Если есть возможность (а обычно для данных задач она есть), много файлов очень элегантно заменяются одним:

# big sparse container — 1Gb
dd if=/dev/zero of=/big-backup-container.raw bs=1024 count=1 seek=1024k
# mkfs
yes|mkfs.ext2 /big-backup-container.raw

# each time backup
mount -o loop,noatime,rw /big-backup-container.raw /mnt/backup
rdiff-backup /very-important-files /mnt/backup
umount /mnt/backup

p.s. надеюсь это объяснять никому не надо? чуть более сложно используется в моих скриптах резервного копирования

[Pilat]

ну нам-то надо иметь возможность отправить на ftp сервер только изменения, а не весь архив.

[disserman]

есть еще третяя категория — те кто видел слёзы первых и проникся.

а вообще инфа существующая в единственном экземпляре — заведомо потеряна.

[vitalyk]

для меня проблема бэкапа решилась с написанием github.com/astrails/safe

[Nastradamus]

А я отношусь еще к более параноидальной категории — делаю бэкапы в 5 точек сразу. :)
А то был печальный опыт с умиранием диска с бэкапом как раз в момент падения сервера (при этом, продакшн и бэкап сервер находились в разных концах города). Я уже не говорю про ситуации, когда в бэкап-сервер находится в одном ДЦ с продакшном…

[Porfel]

Сурово)
Ну я все-же верю, ч то вероятность подобного стремиться к 0, делаю бекапы в одно место.