LINUX.ORG.RU

Автоматизация резервного копирования в Linux

 


0

0

Потеря критически важных данных может оказаться невосполнимой. И тем не менее миллионы профессионалов легкомысленно относятся к резервному копированию своих данных. Если вы - пользователь Linux, то в вашем распоряжении уже имеются исключительно мощные инструменты для создания специализированных решений резервного копирования. Решения, описанные в данной статье, позволяют выполнять как простое, так и более продвинутое сетевое резервное копирование, используя инструменты с открытыми исходными кодами, входящие в состав практически любого дистрибутива Linux.

>>> Подробности

★★★

Проверено: Shaman007 ()

Похоже на кульбит "дрочить, стоя на голове и держа ногами флаг Никарагуа". Как заметил предыдущий оратор, вместо написания собственных лисапедов, можно использовать уже хорошо зарекомендовавшие себя штуковины. Плюс та же бакула.

shutty
()

rdiff-backup и не нужны никакие arc.

anonymous
()

"миллионы профессионалов"

kelyar ★★★★★
()

статья скорее как пользоваться ssh&scp&cron (для тех кто не читает манов и документации), а не о резервном копировании

anonymous
()
Ответ на: комментарий от anonymous

> статья скорее как пользоваться ssh&scp&cron (для тех кто не читает манов и документации), а не о резервном копировании

+1 И не говори =)

KT315
()

а вот можно в Linux сделать так, чтобы * файл хранился на сервере, но имел кэш локально * при отсутствии соединения можно было работать с локальной копией файла, изменять ее * при появлении соединения, кэш незаметно от пользователя обновлял серверную версию ?

savnn
()

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

AiFiLTr0 ★★★★★
()
Ответ на: комментарий от AiFiLTr0

> в моем случае сервак с отдельным веников на 160 гиг, классифицируемым как "ненадежный", бакапит в тар по крону себя, все компы сетки, криптует бакап aes-128 и заливает в фоне по кускам на несколько разных независимых файлхостов как в нашей раше так и за бугром. Раз в месяц тотальный бакап всего, а раз в неделю отдельный бакап субд и еще часто меняющееся по мелочи.

Забыл сказать про "стойкое шифрование перед заливкой на публичные файлхосты". Без этого выпендрёж не был полным.

anonymous
()

Отличная новость - переведена статья, написанная в 2004 году. ;-)

Попытайтесь понять, не читая оригинал статьи, что такое "защищенная оболочка". ;-)

anonymous
()
Ответ на: комментарий от anonymous

$? Expands to the status of the most recently executed foreground pipe‐line.

exit - завершает shell

Таким образом exit $? завершает shell и возвращает результат последней выполненной программы

В противно случае, видимо, он будет возвращать 0

anonymous
()
Ответ на: комментарий от anonymous

> Попытайтесь понять, не читая оригинал статьи, что такое "защищенная оболочка". ;-)

Это быдлоперевод, увы, обычный для межделдмаша.

Понятно: баран-переводчик перевёл secure shell как protected shell :))). А отдел локализации межделмаша не отфильтровал, так как был уволен полным составом с целью экономии средств ещё в том самом 2004 году... :(((

Orlusha ★★★★
()
Ответ на: комментарий от Orlusha

Кроме того, вообще-то, в юниксах shell -- это не "оболочка", а "интерпретатор команд". Shell переводится как "оболочка" в... венде: там это то же самое, что проводник. :) И никак не командная строка: cmd.exe и command.com -- это command line, а не shell.

PowerShell -- это shell в том же смысле, что и в юниксах (так как это есть вариация на тему osh), и к проводнику эта штука никакого отношения не имеет.

Orlusha ★★★★
()
Ответ на: комментарий от Orlusha

> Потеря критически важных данных может _казаться_ невосполнимой

anonymous
()

Немного не в тему.

BackupPC бекапит виндовый сервер. Сегодня выдал в лог

2009-01-14 05:27:55 Backup failed on srv-003 (Didn't get entire file. size=210777, nread=131040) и остановип работу. Как узнать на каком файле он споткунлся, и можно ли его настроить чтобы бекап продолжался после такой ситуации?

anonymous
()

Странный путь бекапа.. tar+bzip2+ncftp всему голова.

holka
()
Ответ на: комментарий от anonymous

+. Причем даже не рассмотрены ни инкрементальные, ни дифференциальные бекапы (которые в легкую делаются при помощи тех же bash+tar+ssh+scp+cron+bzip2?). В итоге, статья не очень полезна с практической точки зрения.

Qasta
()

очередной велосипед Всё придумали за (до) нас - rsnapshot

gentoo admin

anonymous
()

Я бэкап обычно в /proc делаю. Быстро и места не занимает.

anonymous
()

Это полнейший берд. Это что очень удобное имея всего один сервер, когда он себя же и бекапит, НО это не бекап. А где инкрементальный или дифференциальный ? А где единый центр управления ? (я знаю что и у тара есть инкремент, но я говорю о юзабельности и скорости восстановления)

От себя. Когда у меня возник вопрос бекапов (более 30 серверов), было перепробовано много чего, и тот же tar.... в итоге выбор был остановлен на bacula. Если есть у кого какого рода вопросы, чем смогу тем помогу.

PUZO
()
Ответ на: комментарий от anonymous

time machine делается на gnu-шных утилитах cp и rsync

сначала создаем первый снапшот в директории скажем 20090114

mkdir -p /backup/20090114

rsync -aH /path/local/file /backup/20090114/local rsync -aH --rsh="ssh" user@remote.host:/path/to/remote/file /backup/20090114/remote

завтра или когда там делаем скажем 20090115

mkdir -p /backup/20090115

потом создаем там дерево жестких ссылок на вчерашние файлы

cp -al /backup/20090114 /backup/20090115

и теперь синхронизируем новую директорию с источником

rsync -aH /path/local/file /backup/20090115/local rsync -aH --rsh="ssh" user@remote.host:/path/to/remote/file /backup/20090115/remote

получаем в директории /backup/20090115 полный снапшот дерева. При этом скачаны будут только новые файлы. таким образом можно хранить снапшоты деревьев за месяц или сколько там вам надо и не задумываться о размере и не тарить ничего и не жать всякими lzma. И для того чтобы взять какой-нить файл не надо расковыривать громадные tar-ы, просто скопировал файл и готово.

Скрипт сами напишете. А ibm-еры молодцы.

anonymous
()

ну почему когда я вижу долбоебический заголовок с «новостями» из прошлого века, мне даже не надо смотреть, кто запостил?

anonymous
()
Ответ на: комментарий от anonymous

> При этом скачаны будут только новые файлы

А изменения в старых нам, естественно, глубоко до фонаря.....

anonymous
()
Ответ на: комментарий от anonymous

rsync знает свое дело. всё будет хорошо. и новые и измененные старые файлы будут скачаны.

anonymous
()
Ответ на: комментарий от anonymous

>> При этом скачаны будут только новые файлы

>А изменения в старых нам, естественно, глубоко до фонаря.....

+1 ?

anonymous
()
Ответ на: комментарий от anonymous

>rsync знает свое дело. всё будет хорошо. и новые и измененные старые файлы будут скачаны.

>anonymous (*) (15.01.2009 8:06:30

ну дык в старых снапшотах будет сюрприз тогда =)

anonymous
()
Ответ на: комментарий от PUZO

> в итоге выбор был остановлен на bacula. Если есть у кого какого рода вопросы, чем смогу тем помогу.

Вопрос такой: рассматривался ли BackupPC, если да, почему был отвергнут? Просто сам сейчас выбираю между bacula и BackupPC для бекапа нескольких linux-серверов и одного win-сервера

dexpl ★★★★★
()
Ответ на: комментарий от anonymous

нет. rsync переписывая файл создает новый. старый файл остается в старых снапшотах. Вы бы не трендели тут а попробовали сами. Я так уже несколько лет бэкаплю всё. Кстати так сделан сайт http://snapshot.debian.net Там старые снапшоты не удаляют. Но тем не менее с этого сайта можно скачать полный снапшот дебиановского дерева пакетов за любой день из последних нескольких лет. и любой архитектуры. Теперь фтыкаем сюда http://snapshot.debian.net/du/df.png Неужели вы думаете что 4 терабайта хватит для хранения всех снапшотов дебиановского дерева за каждый день из 6 лет для всех архитектур?

anonymous
()
Ответ на: комментарий от dexpl

>> в итоге выбор был остановлен на bacula. Если есть у кого какого рода вопросы, чем смогу тем помогу.

>Вопрос такой: рассматривался ли BackupPC, если да, почему был отвергнут? Просто сам сейчас выбираю между bacula и BackupPC для бекапа >нескольких linux-серверов и одного win-сервера

Да смотрел, но что-то мне там не понравилось, а вот что вспомнить не могу :( Bacula очень мощный и гибкий инструмент для бекапов. Стукнись в аську 999336 расскажу что и как, а то двумя словами не описать :)

PUZO
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.