Получил нахаляву

еще есть?

tar|ssh

А как tar будет бэкапить логи и прочие файлы, открытые на данный момент для записи? И как делать потом восстановление из такого бэкапа на живой системе, чтобы откатить её назад?

да, самое ж главное

Бекапить всю фс - бессмысленно. Делать бекапы нужно только полезной информации. Все остальное должно легко переустанавливаться заново с какого-то конфига установки системы

Это оффтоп. Про халяву нужно спрашивать тут Инвайты (3)

бэкап файловой системы виртуального сервера по ssh

Rsnapshot. Восстановление через копирование

cp -ax ... ...

Бекапить всю фс - бессмысленно. Делать бекапы нужно только полезной информации. Все остальное должно легко переустанавливаться заново с какого-то конфига установки системы

Это виртуальный сервер, для работы используется KVM-виртуализация., устанавливается система из образа. Допустим в процессе работы я решил совершить действие, в котором я сомневаюсь, установить несколько программ, например, и я делаю бэкап. Потом что-то идёт не так и я решаю откатиться на момент создания бэкапа. Как это сделать? cp и tar не подходят, потому что нужно чтобы не только содержимое ключевых файлов было возвращено к изначальному виду, но и исчезли файлы, которых ранее не было.

А снепшотов тебе нахаляву к этой машине не отсыпали? Даже в самом дешевом хецнере можно делать.

нужно чтобы не только содержимое ключевых файлов было возвращено к изначальному виду, но и исчезли файлы, которых ранее не было

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

dd

dump/restore

А как tar будет бэкапить логи и прочие файлы, открытые на данный момент для записи?

https://docs.oracle.com/cd/E37670_01/E37355/html/ol_freun_xfs.html

You can also use the xfs_freeze command with btrfs, ext3, and ext4 file systems.

делать потом восстановление из такого бэкапа на живой системе, чтобы откатить её назад?

ZFS

для работы используется KVM-виртуализация., устанавливается система из образа. Допустим в процессе работы я решил совершить действие, в котором я сомневаюсь, установить несколько программ, например, и я делаю бэкап. Потом что-то идёт не так и я решаю откатиться на момент создания бэкапа. Как это сделать? cp и tar не подходят, потому что нужно чтобы не только содержимое ключевых файлов было возвращено к изначальному виду, но и исчезли файлы, которых ранее не было.

ZFS ONLY

Функция создания снапшотов, как говорит техподдержка, пока отсутствует.
Да, и забыл сказать, файловая система там - ext4

rsync

Как потом делать восстановление из такого бэкапа?

Хм. Тебе чтоли дают доступ в xen-консоль? Какая виртуализацию у них?

План таков:

• бэкап данных, настроек
• все накрылось
• разворачиваешь бэкап

Следи за файлами типа /etc/fstab, где используются UUID'ы. /etc/passwd, по мимо файла надо еще диры создавать если не пробэкапил. Не лучший план, но по крайне мере не зависит от того, съедишь ты на другой хостинг или останешься на этом. На другом хостинге возможно не дадут возможность лить свои образы с ОС.

В этой стране это никто не умеет делать. Даже когда у них в распоряжении vmware. А почему? А потому диски под бэкапы в стоимость услуги не включили.

Потом что-то идёт не так и я решаю откатиться на момент создания бэкапа. Как это сделать?

Купить vmware workstation и играться на локалхосте. Серьезно.

Без поддержки со стороны хостера любой путь решения твоей проблемы будет через реинстал ОС на 20-30 минут и накатом твоего бэкапа. И это если еще инет быстрый и хостер не режет полосу. В противном случае твой роллбэк затянется на час-два. Если тебя такой вариант устраивает, то можешь сделать скрипт по ребуту, который делает бэкап (все процессы поостанавливаются, все хэндлеры позакрываются и простой на несколько минут, может час). После этого ОС загружается, запускается демоны, открываются логи и ты сливаешь бэкап себе.

https://www.opennet.ru/base/sys/rsync_backup.txt.html

да епт. кто мешает морозить ФС xfs_freeze и делать dump (dump умеет по ssh)

xfs_freeze

файловая система там - ext4

ZFS ONLY

Да ты че? Вот прямо таки ONLY?

qcow2 snapshot уже отменили?

И как делать потом восстановление из такого бэкапа на живой системе, чтобы откатить её назад?

На виртуальном сервере? Да никак, в лучшем случае делай lvm snapshot с него и откатишься (lvconvert --merge, и да merge это откат назад)

ZFS тут каким боком советуют не понятно, на lvm или loop-device строить zpool что-ли? Ах, да, это же свидетли zfs, фанатики.

файловая система там - ext4

И? man xfs_freeze

окромя xfs она умеет морозить btrfs, ext3, and ext4

https://docs.oracle.com/cd/E37670_01/E37355/html/ol_freun_xfs.html

qcow2 snapshot уже отменили?

ОЙ МА, когда энто qcow2 стало ФС?

xfs_freeze ext3/ext4 и dump/restore - бекапь наживую.

man rsync.

Ну нахера вот дампить ФС, если rsync-ом бэкап сделать можно? Ты б еще dd в качестве решения предложил.

А как tar будет бэкапить логи и прочие файлы, открытые на данный момент для записи?

когда она примонтирована r/o

И как делать потом восстановление из такого бэкапа на живой системе

никак O_o

кури btrfs snapshots, стильно, модно, молодежно.

встречный вопрос нахера синькать фс когда задампить можно? Да синькать живую ось энто сильно!

Бекапить всю фс - бессмысленно.

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

Одна из задач, которую должен уметь делать админ - это бэкапы. Меня правда многим вещам не учили, приходится до всего доходить самому, так что то, что мои вопросы звучат для кого-то странно я не удивляюсь.
В своё время уже задавался вопросом как сделать бэкап корневого раздела, вот тема моя на юниксфоруме до сих пор жива http://unixforum.org/index.php?showtopic=131179
С тех пор пользуюсь dump/restore. Хотя и про rsync, который тут упомянался тоже слышал. На локальном сервере бэкап я делую так:

dump -0au -f - /dev/sda1 | gzip > dumpfile.gz

Без поддержки со стороны хостера любой путь решения твоей проблемы будет через реинстал ОС на 20-30 минут и накатом твоего бэкапа.

Но мне бы хотелось углубиться в теорию. По какому принципу вообще работают dump и rsync? Вот перед тем как сделать restore я создаю файловую систему на диске, сама restore файловую систему не создаёт. А значит dump/restore работает не на уровне файловой системы, а на уровне отдельных файлов и принцип их работы в общем случае ничем не отличается от принципа работы простых утилит для работы с файлами: tar и cp. А если уж я бэкаплю на файловом уровне, то я должен сначала:
1. Если у меня открыты бд я должен заставить их сбросить кэш на диск.
2. Перемонтировать корневую фс в r/o.
3. Уже после этого делать бэкап причём передавать его сразу по ssh, на диск сохранить будет невозможно, поскольку он в r/o.
Буду признателен тому кто объяснить мне как эти три пункта выполняются.

Сбрасывать кеши БД на диск смысла нет, если вы планируете переводить ФС в ro, то нужно просто останавливать (килять) все службы, пишушие на диск — базы данных, логи, почтовый сервер и т.д. Грубо говоря всё, кроме sshd.

А потом, любая команда и поток в ssh, типа

cat file.txt | ssh any.host «cat > out.file»

Такой конвеер перенаправит содержимое файла file.txt на stdin команды cat, пишущей в файл out.file на хосте any.host. И с этим можно потренироваться отдельно, без задачи бэкапа.

Что касается восстановления, то нужно потренироваться переносить корень в tmpfs (ОЗУ), через создание там рабочего chroot окружения, можно просто копирую, можно busybox + sshd, монтирования туда /dev, /proc, /sys и pivot_root (естественно, покиляв все ненужные процессы). Тогда у вас реальная корневая ФС полностью свободна и делайте с ней что угодно.

Однако с удалённым и к тому же виртуальным сервером такой способ не прокатит потому что тут невозможно загрузиться с Live CD.

Поправка: у vscale.io нельзя. Некоторые дают возможность грузить любой iso.

Но мне бы хотелось углубиться в теорию. По какому принципу вообще работают dump и rsync?

dump может бэкапировать либо файлы, либо файловую систему. В вашем случае происходит копирование файловой системы с учетом i-nodes. Поэтому важно, чтобы файловая система поддерживалась утилитой dump. Напротив, rsync копирует файлы вне зависимости от типа файловой системы, главное чтобы их можно было прочитать и записать через вызовы read(2), write(2).

Рассмотрим минусы каждого из подходов. Минусом dump, в контексте использования, является необходимость, чтобы файловая система была размонтирована в момент бэкапа, а также, чтобы в момент восстановления подготовлен отформатированный раздел. Для контраста, утилита dd не зависит от файловой системы и использует блочное копирование, поэтому для ее работы достаточно размонтированный раздел/диск. Т.о. такой вид бэкапа подходит для систем, где есть возможность остановить все сервисы, остановить почти все службы, чтобы не производились никакие дисковые операции.

Минусом rsync является скорость работы. Поэтому он подходит для систем, где важно, чтобы никакие службы в момент бэкапирования не останавливались.

А значит dump/restore работает не на уровне файловой системы, а на уровне отдельных файлов и принцип их работы в общем случае ничем не отличается от принципа работы простых утилит для работы с файлами: tar и cp

Утилита dump в режиме инкрементального бэкапа позволяет удалять файлы на целевом носителе при восстановлении данных. Допустим вы делаете полный бэкап (опция 0), и файл /usr/local/bin/apache будет восстановлен на целевом носителе. Далее, вы решили этот файл удалить, сделали инкрементальный бэкап и восстановили его. После восстановления файла /usr/local/bin/apache вы не найдете, т.к. соответствующие записи на файловой системе были изменены. Этого поведения вы не сможете достичь используя только tar и cp. Однако утилита rsync позволяет это сделать, т.о. воссоздать точную копию на текущий момент.

1. Если у меня открыты бд я должен заставить их сбросить кэш на диск.

В общем случае, от БД требуется часто делать вызов fsync(). Но поскольку в реальности эта операция весьма сильно нагружает файловую систему при частых вызовах, придумали собственные средства для бэкапа БД. Используйте их.

2. Перемонтировать корневую фс в r/o.

В современных системах она всегда замонтированна в ro. Вопрос в разбивке диска.

3. Уже после этого делать бэкап причём передавать его сразу по ssh, на диск сохранить будет невозможно, поскольку он в r/o.

Опять же, вопрос разбивки диска.

--

Суммируя все вышесказанное. Для вашего VPS подойдет подход dump/restore (или dd), если вы (или хостер) грамотно разбили диск перед установкой ОС. В 95% случаев оказывается, что имеется максимум 2-4 раздела: под корень, под /home, /tmp, и swap. Вместо классической схемы: /, /usr, /var, /tmp, /var/tmp, /home. Не нужно сейчас сломя голову бежать переустанавливать систему, раз вы поняли в чем смысл. Современные линуксы (дистрибутив вы не указали) ушли от этих стандартов, в пользу того, что проще установить систему с нуля, и восстановить только нужные данные.

Тем не менее, даже с учетом всего выше сказанного, вы можете делать бэкапы через dump/restore, как вам привычно, не забывая, что надо останавливать сервисы и службы и монтировать корневой раздел в read-only.

А можете воспользовать rsync, который на лету будет копировать только действительно нужные данные. Еще раз повторю, что в случае сложного ПО, такого как БД, ни один стандратный способ бэкапирования не предоставляет гарантий создания рабочих бэкапов, когда БД работает в штатном режиме. Используйте средства БД, если они есть.

Теперь без гаданий на кофейной гуще. Конкретно по пунктам. Ответьте на вопросы ниже:

• Можно останавливать сервисы в любой момент на время необходимое для бэкапа? Время вариируются до часа-двух.
• Имеется ли достаточно свободного места, чтобы уместить полный бэкап всей системы?

Если ответы на оба вопроса положительные, то используйте dump/restore. В противном случае подходит rsync/tar/cp и т.п.

• У меня быстрый интернет и он работает без разрывов?

Если нет, то с учетом отсутствия достаточного свободного места на дисках, у вас остается немного вариантов.

Следующие вопросы о необходимости снимать бэкап всего:

• Мои действия несут разрушительный характер всей системе?
  • Да, я это знаю наверняка.
  • Да, но я не уверен.
• Мои действия это песочница, где я играю как хочу?

100% положительный ответ на первый вопрос означает, что вы действительно подготовленный специалист и вопрос о бэкапах был задан вами в шутку. Неуверенный ответ говорит о том, что следует углубиться в вопросы того, что вы делаете. Выше было высказывание, что вы устанавливаете пакеты и опасаетесь что-то сломать. Пакетный менеджер в своей работе использует небольшое кол-во файлов, которые в 99% случаев очень просто контролировать и для этого не нужны полные бэкапы.

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

• Я просто хочу, чтобы все было просто, быстро, надежно?

Все сразу не бывает. Чтобы я сделал на вашем месте?

• Определился с критичностью запущенных программ. Могу я их останавливать на любой срок или нет? Если нет, добавил варианты, когда это все же возможно
• Определился с тем, что я хочу сделать
• Изучил возможные последствия моих действий (через тестовый стенд или хотя бы прочитал документацию)
• Оценил возможности окружения (медленный интернет, (не-)возможность хранить все бэкапы на сервере)
• Составил план действий
• Подобрал инструменты
• Протестировал их работоспособность

С учетом моего опыта и познаний, в большинстве случаев я выбираю rsync, либо tar. Почему?

• Я знаю, что делаю в большинстве случаев
• В большинстве случаев мне не нужен бэкап всего раздела
• Я на лету восстанавливаю файлы конфигураций
• Пакетный менеджер умеет удалять все ненужные мне файлы, а за своими файлами мне достачно команды find > filelist
• В случае БД я делаю горячие бэкапы средствами БД
• В случае восстановления с нуля всей ОС уже имеется список всех ранее установленных програм
• В момент восстановления система будет иметь те же заголовочные и библиотечные файлы, потому что я часто обновляюсь
• Поэтому не страшно собрать программы в ручную, если это потребуется. А это не потребуется в 50% случаев
• Восстановление системы это нештатная ситуация и я стараюсь ее предотвратить, а не использовать ее в своих играх
• Для игр и стенда есть виртуалки на локалхосте
• Время восстановления системы стоит на последнем месте и я не тороплюсь
• Для песочниц в онлайн я выбираю облачные решения для своих задач
• Когда этого недостаточно я арендую физические сервера

для работы используется KVM-виртуализация

Тунца лососни

И теперь мой самый конкретный совет: поскольку сервер виртуальный и хостер никаких инструментов не дает, ты ничего не делаешь в полученной ОС, все что тебе надо делаешь в chroot, там все программы, настройки и пр.

Бекап, восстановление, тесты, откат, ... элементарно на уровне rsync/tar/cp/...

cp -l позволит бысто и дешево клонировать нужные chroot'ы и тд.

Исче раз dump умеет работать удаленно по ssh, без проблем, дампить ФС НАМНОГО БЫСТРЕЕ ЧЕМ СИНХРОНИЗИРОВАТЬ.

Можно останавливать сервисы в любой момент на время необходимое для бэкапа? Время вариируются до часа-двух.

о каких часах идет речь? дамп ФС емкостью 20ГБ занимает несколько минут и оно реально быстрее чем тарить и синхронить.

Имеется ли достаточно свободного места, чтобы уместить полный бэкап всей системы?

О каком месте идет речь? Дамп работает по ссх и его можно сразу сбрасывать на удаленный сервер, как из развернуть от туда.

Однако с удалённым и к тому же виртуальным сервером такой способ не прокатит

Ты уверен? вариант есть.

лососни сам, у ТС нет доступа к рычагам управления kvm, у него остается тока ФС

о каких часах идет речь?

О полных часах. Полных.

О каком месте идет речь? Дамп работает по ссх и его можно сразу сбрасывать на удаленный сервер, как из развернуть от туда.

Хорошо если у тебя инет высокоскоростной и твой пров имеет прямой линк с провайдером хостера. А если у тебя интернет «не очень»? Секунды превращаются в минуты, минуты в часы, часы в дни.

Опять же в таске ничего не сказано ни про объемы, ни про качество интернета а) у хостера (может там полоса в 100Кб/с) б) у ТС (может у него нестабильный 3g/4g). Я не телепат, поэтому даю оценку с множетелями около х 10.

--

А вот проецировать себя, свое окружение в контексте «у меня все быстро, у меня все летает, поэтому бла-бла-бла и я, только я, прав и мое мнение безошибочное» не работает в реальности. И пихать его во все щели не надо.

Сосунок, на данном этапе наводящих вопросов это было неизвестно, однако ты впердолил zfs, даже не думая. Фанатик одним словом.

Вопрос в разбивке диска.

Один раздел ext4 смонтированный на корень

В современных системах она всегда замонтированна в ro.

Это как это? А как же тогда туда запись идёт?

дистрибутив вы не указали

Debian Jessie

•Мои действия это песочница, где я играю как хочу?

Взял VPS для того, чтобы заиметь себе персональный прокси и персональный Secondary DNS, но в основном всё же для эксперементов, причём идеи некоторых эксперементов мне подсказали уже в этом же треде.

Что касается восстановления, то нужно потренироваться переносить корень в tmpfs (ОЗУ), через создание там рабочего chroot окружения, можно просто копирую, можно busybox + sshd, монтирования туда /dev, /proc, /sys и pivot_root (естественно, покиляв все ненужные процессы). Тогда у вас реальная корневая ФС полностью свободна и делайте с ней что угодно.

То есть я могу не теряя связи с системой по ssh перенести её всю в tmpfs, а после чего хоть переразбить диск, хоть вообще заменить предустановленный дистрибутив любым другим. А в какую сторону копать, чтобы понять как такая магия делается?

Взял VPS для того, чтобы заиметь себе персональный прокси и персональный Secondary DNS

И зачем тогда свястопляски вокруг какой-то БД. Некоторые, в том числе я, полагали, что в БД крутится что-то очень важное.

В вашем случае можно начать играться с тем как делать бэкапы для своей VPS. Вот вообще поставили систему, сделали touch testfile, забекапились, далее rm -rf /. Все. Конец сообщения :)

Ну просто спросил про БД для общего развития.