Комментарии 34
YET ANOTHER BACKUP script :)
Как только не изгаляются люди не желая использовать VCS.
Не VCS а CVS (SVN), и никто не говорит что не использую. Правда для других задач — как бы системы контроля версий несколько для иных целей создавались имхо.
причем тут vsc, если нужно бекапить файловое хранилище?
> в директории с проектом
Не уточнено, что за проект. Я как программист, под проектом подразумеваю толпу исходников, которые лежат в директории.
Если проект- это обработаное видео, то да, другой разговор.
Не уточнено, что за проект. Я как программист, под проектом подразумеваю толпу исходников, которые лежат в директории.
Если проект- это обработаное видео, то да, другой разговор.
VCS помог бы, но при условии что у него можно было бы чистить историю как в rdiff-backup:
rdiff-backup --force --remove-older-than 20D /backups
rdiff-backup --force --remove-older-than 20D /backups
А '--exclude-special-files' не синоним для '--exclude-device-files --exclude-fifos --exclude-sockets --exclude-symbolic-links'?
А если хочу бэкапить не одну, а несколько директорий за раз? Делать кучу копий скрипта?
я делаю вот так:
скрипт раскладывает по папочкам каждый день изменений в отдельности и держит текущую версию в папке 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
скрипт раскладывает по папочкам каждый день изменений в отдельности и держит текущую версию в папке 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
for i in `echo $BACKUP_DIR`; do
...
fiВнутри блок, начинающийся с
if [ ! -d $MOUNTPOINT/$BACKUP_DIR ]; then... и заканчавающийся перед ERRORS=…Внутри блока $BACKUP_DIR на $i поменять, разумеется.
«grep -vc grep» -> «wc -l»
портабельней будет.
портабельней будет.
Рекомендую Bacula
Ресурсов почти не жрет, кстати. Разобраться в настройке можно побыстрее чем написать «YET ANOTHER BACKUP script».
Ресурсов почти не жрет, кстати. Разобраться в настройке можно побыстрее чем написать «YET ANOTHER BACKUP script».
Бакула не удобна тем, что на хранилище надо иметь как минимум bacula-sd, я уж не говорю про наличие fd и director'a.
А у меня на VPS память не резиновая.
А у меня на VPS память не резиновая.
1) ну, могу сказать что все демоны могут находиться даже на одной машине а sd может с таким же успехом складывать архив на удаленную ФС, хотя это извращение конечно и не так безопасно.
2) ресурсов на самом деле потребляет минимум. клиентский fd у меня на VPS кушает ~1.5Мб оперативки
Кстати, вон в комментариях многие жалуются что при смене админа почти всегда приходится менять бекап-скрипты т.к. в чужих никто разобраться не сможет. А бакула промышленное решение, там с этим проблем не должно быть. Если админ бакулу не осилит — в топку такого админа)) Если под себя все делается то этот момент не так актуален конечно.
Хотя в целом конечно по ситуации надо смотреть. Если у вас 1-2 сервера, а то и просто виртуальный хостинг, то можно скриптами отделаться.
Но если что-то посерьезнее — то нужно и решение соответствующее.
2) ресурсов на самом деле потребляет минимум. клиентский fd у меня на VPS кушает ~1.5Мб оперативки
Кстати, вон в комментариях многие жалуются что при смене админа почти всегда приходится менять бекап-скрипты т.к. в чужих никто разобраться не сможет. А бакула промышленное решение, там с этим проблем не должно быть. Если админ бакулу не осилит — в топку такого админа)) Если под себя все делается то этот момент не так актуален конечно.
Хотя в целом конечно по ситуации надо смотреть. Если у вас 1-2 сервера, а то и просто виртуальный хостинг, то можно скриптами отделаться.
Но если что-то посерьезнее — то нужно и решение соответствующее.
Когда дело касается баша, мне проще самому для своих задач написать, чем разбирать чужие скрипты.
А так да, использую rdiff-backup. И ещё rsync, так как он быстрее синхронизирует дерево, а это важно для соблюдения целостности также бекапящейся базы данных, которая ссылается на файловую.
А так да, использую rdiff-backup. И ещё rsync, так как он быстрее синхронизирует дерево, а это важно для соблюдения целостности также бекапящейся базы данных, которая ссылается на файловую.
Не так давно выбирал себе что-нибудь для бэкапа, и rsnapshot понравился больше, чем rdiff-backup. Настройка несколько прозрачнее и удобнее. Несколько уровней копий (ежечасные, ежедневные, и т. д.) с независимыми расписаниями, восстановление до любого состояния простым копированием, и работает, как мне показалось, быстрее.
Всё, что генерирует много файлов, плохо для хранения бэкапа на внешнем сервере. Как, например, эти файлы перенести на FTP сервер? Никак, очень будет медленно. Восстановление пофайловое с внешнего сервера тоже небыстрое.
Самый простой способ — основывать бэкапную систему не на rdiff-backup, а на dar, конечным продуктом будет один файл на первую копию (full) и по одному файлу на инкрементальные. В качестве обвязки можно использовать www.backup-manager.org/. Кстати, в случае с dar инкрементальную копию можно получить, не храня на компьютере full копию, можно хранить только метаинформацию от неё.
Самый простой способ — основывать бэкапную систему не на rdiff-backup, а на dar, конечным продуктом будет один файл на первую копию (full) и по одному файлу на инкрементальные. В качестве обвязки можно использовать www.backup-manager.org/. Кстати, в случае с dar инкрементальную копию можно получить, не храня на компьютере full копию, можно хранить только метаинформацию от неё.
Спасибо, возьму на заметку.
Если есть возможность (а обычно для данных задач она есть), много файлов очень элегантно заменяются одним:
# 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 backupp.s. надеюсь это объяснять никому не надо? чуть более сложно используется в моих скриптах резервного копирования
mount -o loop,noatime,rw /big-backup-container.raw /mnt/backup
rdiff-backup /very-important-files /mnt/backup
umount /mnt/backup
есть еще третяя категория — те кто видел слёзы первых и проникся.
а вообще инфа существующая в единственном экземпляре — заведомо потеряна.
а вообще инфа существующая в единственном экземпляре — заведомо потеряна.
для меня проблема бэкапа решилась с написанием github.com/astrails/safe
А я отношусь еще к более параноидальной категории — делаю бэкапы в 5 точек сразу. :)
А то был печальный опыт с умиранием диска с бэкапом как раз в момент падения сервера (при этом, продакшн и бэкап сервер находились в разных концах города). Я уже не говорю про ситуации, когда в бэкап-сервер находится в одном ДЦ с продакшном…
А то был печальный опыт с умиранием диска с бэкапом как раз в момент падения сервера (при этом, продакшн и бэкап сервер находились в разных концах города). Я уже не говорю про ситуации, когда в бэкап-сервер находится в одном ДЦ с продакшном…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой скрипт для инкрементального бекапа директорий