Резервное копирование
vitek 29 октября, 2009 - 10:27
Имеется программа с базой DBF, лежит все это чудо на Gentoo сервере. Нужно настроить резервное копирование этой базы два раза в сутки. Собственно как это правильнее сделать?
У меня мысль просто в крон засунуть задание на копирование. Но тут проблема в том что получится затирание базы и вполне может получится что нормальная копия просто затрется битым файлом с очередным копирование по крону. Как решить эту проблему? Есть мысль сделать копирование в файл имя которого будет отображать дату и время на момент копирования, но тогда придется руками чистить лишние копии так как за месяц их будет просто нереальное кол-во. Как решить эту задачку чувствую истина где-то рядом посоветуйте что-нить люди добрые!
»
- Для комментирования войдите или зарегистрируйтесь
vitek написал(а): Есть мысль
А по крону искать и удалять файлы, старше недели(месяца, или сколько там надо)?
ЗЫ А не изобретать велосипед, и воспользоваться, скажем, бакулой?
Эгоист, это тот человек, которых думает о себе, вместо того, чтобы думать обо мне.
Ĉu vi komprenas min?
tar и date --help не устроят?
tar и date --help не устроят?
буду честен, я не знаю, почему у меня все работает
app-doc/abs-guide
Например:
ROTATE=64 # rotate FILES=`ls $REPORT_DIR/assp-stat* | wc -l` if [ "$FILES" -gt "$ROTATE" ] then DELETE=`expr $FILES - $ROTATE` CLEAR=`ls -r1 $REPORT_DIR/$REPORT-NAME.* | tail -n $DELETE` for TEMP in $CLEAR do rm -f $TEMP done fiИ будет тебе счастье.
ЗЫ: Правда, оно потребует правильного формирования суффикса, содержащего дату...
:wq
--
Live free or die
А можно чуточку пояснить
А можно чуточку пояснить :-[
+ посмотрел в сторону бакулы (немного испугался :)) Мне кажется уж очень нагромождено получается
Почитал мысль не уловил простите. Если не сложно поясните что имелось в виду
Бакула имеет смысл при
Бакула имеет смысл при наличии нескольких серверов. В данном конкретном случае применение сего инструмента возможно выглядит несколько излишне, но использовать готовую систему резервного копирования следует из расчета возможного масштабирования задачи резервирования данных. Собсно в любой готовой системе резервного копирования перечисленные вами проблемы решены.
Про tar и date и ловить не чего. Два инструмента, активно использующихся для написания велосипедов резервного копирования. Примеров их в использования в нете полно. Вам рекомендовали ознакомиться с консольной подсказкой. Я бы посоветовал info date и info tar.
Несколько серверов есть, но
Несколько серверов есть, но масштабировать к сожалению видимо ничего не придется. Во всяком случае не так скоро как хотелось бы. Я не понял почему бакула имеет смысл при наличии нескольких серверов? Оно как бы и один не мешало-бы бэкапить, чем бакула плоха в случае с только одним сервером? Насчет консольной подсказки, я не нашел ничего нового собственно почему и уточнил что имелось в веду :) буду ковырять бакулу или еще что-нить а там посмотрим.
Собственно о существовании систем резервного копирования я как бы знаю давно, просто конкретно в этом случае не хочется возится с чем-то серьёзным, думаю просто выделить пару часиков и придумать две три строчки для крона и на этом пока остановится.
>>Я не понял почему бакула
>>Я не понял почему бакула имеет смысл при наличии нескольких серверов?
Это клиент-сервер. С опционным сжатием данных на клиенте, чтоб по сети менше тянуть. С каталогом бекапов на mysql. C почтовыми уведомлениями. Со скриптами, которые могут выполняться перед или после бэкапа на сервере бэкапов или на клиенте. С хранилищем данных, который выглядит как сетевой сервис и может быть установлен отдельно от всей системы. Плюс к тому резервирование сам на сам - плохая идея. Как минимум должно быть два девайса. Все это достаточно трудоемко в освоении и настройке. Для одного сервака выглядит не очень привлекательно. А насчет масштабирования. Да пусть пишет несколько серваков. Лишь бы места хватило. Он ведь не нужен никому. Бекап этот ваш. До поры до времени :).
Что касается тара. Готовых примеров масса. Один из них http://www.opennet.ru/base/sys/backup_sh.txt.html. Можно и скриптом отрулить. Только есть реалная опасность разрастания его до объемов и функционала бакулы со временем.
Есть еще аманда. С ней у меня чегото не срослось. Интересный вариант резервирования app-backup/backuppc c подавлением дублей файла, и системы p2p, использующие винты соседей в качестве хранилища.
.
Суффикс должен быть таким, чтобы последние в списке, выводимом по
ls(в общем случае не один штук) файлов совпадал с последними по хронологии.В
man lsзакапываться мне было лень, поэтому я использую суффикс вида (в смысле: формируемый командой)date "+%Y-%m-%d".:wq
--
Live free or die
ls -t насколько я помню
ls -t насколько я помню сортирует по дате. Помоему это проще
vitek написал(а): посмотрел в
Да, на первый взгляд штука страшноватая. На самом деле всё логично и просто (Нужно только денёк покурить инет и родную документацию). Зато потом можно сохранять и восстанавливать всё и вся.
Эгоист, это тот человек, которых думает о себе, вместо того, чтобы думать обо мне.
Ĉu vi komprenas min?
man find
# find /example/ -ctime +3 -delete
Таким образом буду найдены файлы в папке example старше 3 дней и удалятся.
Если че не так поправте.