История изменений

Однако с удалённым и к тому же виртуальным сервером такой способ не прокатит потому что тут невозможно загрузиться с 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, который на лету будет копировать только действительно нужные данные. Еще раз повторю, что в случае сложного ПО, такого как БД, ни один стандратный способ бэкапирования не предоставляет гарантий создания рабочих бэкапов, когда БД работает в штатном режиме. Используйте средства БД, если они есть.

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

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

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

dump может бэкапировать либо файлы, либо файловую систему. В вашем случае происходит копирование файловой системы с учетом i-node. Поэтому для важно чтобы файловая система поддерживалась утилитой 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, который на лету будет копировать только действительно нужные данные. Еще раз повторю, что в случае сложного ПО, такого как БД, ни один стандратный способ бэкапирования не предоставляет гарантий создания рабочих бэкапов, когда БД работает в штатном режиме. Используйте средства БД, если они есть.