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