Резервирование с помощью rsync

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

RAID0

*facepalm*

Магия LVM нужна для снятия снапшота при условии:

Останавливаешь активные программы

А так задача ТС не решается rsync'ом, потому как с его слов:

Рабочая система у меня в RAID10. Но это не спасает от вирусов, хакеров, ошибок в системе и т.д.

Поэтому, если у него будет затёрт /boot или конифги какого демона, то система будет работать до презагрузки, а снять с неё загрузочную копию уже нельзя.

А rsync вообще имеет слабое отношение к бекапам. Тебе скорее нужен rdiff-backup.

Ты уж определись тебе резвирование данных нужно или рабочая система с которой можно загрузиться. Вариант засосать испорченные или удаленные данные на резервный диск ты в принципе не рассматриваешь?

удаленный бекап системы в runlevel 1

зачем удаленный, локальный, на резервный диск.

если сервер - локалхост

за сутки изменялось порядка 5-10гигов данных, rsync это проглатывал ну максимум за 10 минут. Это происходило ночью 1 раз в сутки.

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

работать оно работает, но рекомендовать я-бы не рискнул. У меня как-то было, что восстановить не получилось. К счастью, то был тестовый сервер, да и таблицу можно было создать ещё раз(что я и сделал).

Магия LVM нужна для снятия снапшота при условии:

Останавливаешь активные программы

ну и зачем тогда нужна эта магия, если можно хоть dd копировать? Пока стоит.

А так задача ТС не решается rsync'ом,

от самого себя никакая магия не спасёт.

А rsync вообще имеет слабое отношение к бекапам.

для бекапов rsync не очень удобен. Вот если бекап уже сделан локально, и надо синхронизировать с удалённым хранилищем — то годно.

Пока не знаю всех возможностей rsync, поэтому о пригодности спорить не буду.
В таком варианте резервного копирования меня привлекает то, что можно в случае чего быстро загрузить сервер с резервного диска с вчерашней, например, копией рабочей файловой системы и из-под нее-же (копии) восстановить рабочую файловую систему.
Попробовал этот вариант на ноутбуке. Скопировал рабочую файловую систему на другой раздел. Подправил /boot/grub/grub.cfg и /etc/fstab.
Загрузился. ОС загрузилась вроде нормально, а X-сервер запускаться не захотел. Еще не разбирался почему.
Для копирования использовал команду:
rsync -a --delete --exclude=/backup --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/sys / /backup

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

tar ничем не хуже ИМХО. Всё равно надо всё останавливать.

Загрузился. ОС загрузилась вроде нормально, а X-сервер запускаться не захотел.

я tar'ом Over9000 раз так делал:

1. растариваешь тарбол прямо в корень

2. /sbin/lilo

3. ??????????

4. PROFIT

только надо откуда-то загрузится, и после п1 чрутится.

Почему пока стоит? Пока снапшот есть, то есть пока LVM хватает места не переписывать снапшот. Создаётся снапшот быстро, так что демонов останавливать надолго не надо. А потом хоть rsync, хоть tar, хоть dd копируй.

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

Я не знаю, насколько это правильно, но по идее rsync может не трогать файлы с совпадающим размером и временем. Поэтому, для задачи регулярного обновления резервного диска rsync может быть удобнее, чем tar. Насколько я понял, ТС ведь хочет регулярно снимать копию — обновил систему и снял копию обновлённой системы. Тогда rsync может быть быстрее, чем tar всей ФС или dd всего раздела.

А /dev, /proc и другие каталоги были созданы?

Да

Почему пока стоит? Пока снапшот есть, то есть пока LVM хватает места не переписывать снапшот.

ну потому, что когда ты создаёшь снапшот, то это просто сигнал к тому, что-бы НЕ возвращать блоки, которые стали свободными. Потому эти блоки так и остаются занятыми. Т.е. данные при создании снапшота не переносятся, а переносится только структура (создаётся вторая). Когда ты переписываешь файл, старый файл не удаляется из копии структуры, а удаляется только из оригинала. Это всё работает, но только если у тебя файлов немного(структура маленькая) И файлы у тебя именно перезаписываются, т.е. старый файл удаляется, а новый пишется.

А ещё с LVM легче сделать отдельную файловую систему под базы данных

в СУБД файлы являются всего лишь контейнерами, и не переписываются целиком. Структура СУБД известна только самой СУБД, потому скопировать её снапшотом невозможно. Придётся твоей системе останавливать ВСЁ, и копировать данные. Потому СУБД так не бекапят, если есть возможность остановить СУБД ненадолго, то делают дамп(в смысле средствами СУБД), если ТЗ этого не позволяет, то делают репликацию.

Насколько я знаю, никакой магии не придумали, а как это обойти без магии — я тоже не знаю.

Если приложение активно работает с файлами, то тоже проблема — Over9000 файлов переписываются правильно, но сама структура слишком сложна, потому снапшот тоже делается очень долго.

Ну и наконец, если и СУБД бекапить не нужно, и структура не сложная, то зачем тут снапшоты, когда простой tar всё это тоже быстро сделает?

Я не знаю, насколько это правильно, но по идее rsync может не трогать файлы с совпадающим размером и временем. Поэтому, для задачи регулярного обновления резервного диска rsync может быть удобнее, чем tar.

фишка в том, что tar _тоже_ может не трогать такие файлы с опцией --update. Но tar не лезет внутрь файлов(а вот rsync — лезет, сабака), потому

1. tar работает быстрее

2. tar не требует tar на удалённой стороне.

Вообще говоря, rsync намного мощнее tar, но её мощь она не слишком нужна именно для бекапа.

я думаю, проблема в том, что cp неправильно сработала с симлинками. Или с временными штампами. Или с правами. Вариантов много.

Локальный бекап уже защищает от `rm -rf /`? Хорошо - это шутка, не шутка, что на скомпрометированой системе этот «локальный бекап» так же будет скомпрометирован.

Да, я как раз говоря про бекапы и rsync имел ввиду rdiff-backup, т.к. сам rsync имеет к бакап такое же отношение, как и cp.

Локальный бекап уже защищает от `rm -rf /`? Хорошо - это шутка, не шутка, что на скомпрометированой системе этот «локальный бекап» так же будет скомпрометирован.

а кто тебе запрещает делать удалённую копию локального бекапа? Тут уже не нужен init 1, да и вообще — пусть хоть весь день делается.

Останавливаешь активные программы, делаешь lvm снапшот, запускаешь программы (всё это занимает +- минуту).

Вау! Вот я дурак, неправильно свои diff ежедневные на 150-200G бэкаплю. Оказывается снэпшот их за минуту бэкапит.

читать научись, клоун.

Что не так, умник?

ну потому, что когда ты создаёшь снапшот, то это просто сигнал к тому, что-бы НЕ возвращать блоки, которые стали свободными. Потому эти блоки так и остаются занятыми. Т.е. данные при создании снапшота не переносятся, а переносится только структура (создаётся вторая). Когда ты переписываешь файл, старый файл не удаляется из копии структуры, а удаляется только из оригинала. Это всё работает, но только если у тебя файлов немного(структура маленькая) И файлы у тебя именно перезаписываются, т.е. старый файл удаляется, а новый пишется.

Здесь http://www.tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html как бы не согласны:

Read-only snapshots work by creating an exception table, which is used to keep track of which blocks have been changed. If a block is to be changed on the origin, it is first copied to the snapshot, marked as copied in the exception table, and then the new data is written to the original volume.

Честно говоря, я вобще не понял описанного вами алгоритма. «НЕ возвращать блоки, которые стали свободными.» Свободными где, на каком уровне? Если на уровне ФС, то LMV нихрена не знает, какой блок с данными файла, а какой свободен. Делается снапшот именно блочного устройства, ФС на блочном устройстве аналог СУБД на файле, ФС изменяет содержимое блоков с инодами, как СУБД изменяет содержимое блоков с данными файла.

И вот пример «быстрого» бекапа СУБД: http://www.lullabot.com/blog/article/mysql-backups-using-lvm-snapshots и под него желательно именно отдельный том LVM для СУБД.

Если ты хочешь решить задачу, а не страдать ерудной, то тебе нужно поднять RAID0.

Хороший путь к успеху. АААААА.....жесткач

″cp″? ТС же привёл команду ″rsync″. Но ″-а″ не включает ″-H″, ″-X″, ″-A″, то есть хардлинки, xattr и acl'ы. Кажись, здесь уже была тема, что без xattr Ubuntu не клонируется.

Read-only snapshots work by creating an exception table, which is used to keep track of which blocks have been changed. If a block is to be changed on the origin, it is first copied to the snapshot, marked as copied in the exception table, and then the new data is written to the original volume.

здесь тоже самое говорится, что и я выше пытался объяснить. Даже лучше.

Если на уровне ФС, то LMV нихрена не знает, какой блок с данными файла, а какой свободен.

знает. If a block is to be changed on the origin.

И вот пример «быстрого» бекапа СУБД: http://www.lullabot.com/blog/article/mysql-backups-using-lvm-snapshots и под него желательно именно отдельный том LVM для СУБД.

ну делай. Я же не говорил, что «нельзя», я говорил, что это может всё затормозить. Если ты всё в RO перевёл, получится может и неплохо, вот только дамп сделать всё равно быстрее, причём прямо на живой СУБД.

Была такая задача и я ее выполнил и это не самая странная задача в моей практике.

на скомпрометированой системе этот «локальный бекап» так же будет скомпрометирован.

а на это мне было мягко сказать положить.

Что не так, умник?

Останавливаешь активные программы, делаешь lvm снапшот, запускаешь программы (всё это занимает +- минуту).

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

rsync

man dd

«Но ″-а″ не включает ″-H″, ″-X″, ″-A″, то есть хардлинки, xattr и acl'ы. Кажись, здесь уже была тема, что без xattr Ubuntu не клонируется.»

Уже писал, что после выполнения команды
rsync -a --delete --exclude=/backup --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/sys / /backup
ОС загрузилась с резервного раздела, но X-сервер не запустился.
Выполнил из основной файловой системы команду
rsync -a --delete --exclude=/backup --exclude=/proc / /backup
(на этот раз не загружая иксы) и получил большое количество ошибок, связанных с директорией /sys .
Повторил rsync , включив в exclude директорию /sys :
rsync -a --delete --exclude=/backup --exclude=/proc --exclude=/sys / /backup .
Последняя команда завершилась за пол-секунды.
Файлы /etc/fstab и /boot/grub/grub.cfg уже править не пришлось.
Система нормально загрузилась с резервного раздела, в т.ч. и X-сервер.
Сейчас пишу из-под резервной файловой системы. Никаких замечаний пока нет. Все работает как обычно. Дальше буду посмотреть.