dump/restore сервера наживую

Классические БД вроде PostgreSQL такого точно не любят и полученная путем копирования «на живую» БД будет испорченной. Максимум что можно сделать – запросить snapshot на уровне файловой системы и его перенести. При старте он будет восстанавливаться, но в итоге взлетит как надо.

Максим, здравствуйте, спасибо за ответ. У меня до туда только доступ по ssh есть, что-то другое запрашивать накладно. Система виртуализации VMWare. Планирую подмонтировать к этому серверу сетевую шару по sshfs и в туда дампить.

А зачем так? Может проще через репликацию?

В смысле, репликацию БД? Да, это наверное проще, но мне надо перенести весь сервер в другое место. База данных тут потому, что она при этом может создать проблему.

Так может тогда в два приема, отдельно фс и отдельно базу?

Ну вот к чему и вопрос, при дампе корневой фс ничего с базой на _исходной_ виртуалке не может случиться, что ее нужно будет восстанавливать из резервной копии?

какая вероятность того, что

50%

Если у вас переезд и выполняемый, искреннее простите за грубость, «человеком задающим такие вопросы на ЛОРе», то имхо однозначно даунтайм предусмотрен «из каробки». «Гасите» сервак, на все вопросы отвечаете «оно само поломалось» и спешно но не торопясь переливаете данные.

нет. при чтении (dump) ни с файловой системой ни с файлами на исходной стороне ничего не случится.

лучше остановить/выключить систему и средствами vmware сделать снапшот виртуалки. потом включить на дальнейшую работу. это займет секунды очень мало времени.
апосля уже не торопяся копировать из снапшота.

А что мешает использовать программу дамп от базы данных?

mysqldump, например?

Изучи fsfreeze. Возможно это то, что тебе поможет.

dump для корня файловой системы испортит базу данных MongoDB (её исходные файлы), если во время дампа кто-то из MongoDB будет читать или в неё же писать?

Оригинал не испортит, а вот копия будет битой с вероятностью близкой к единице (если за время дампа будет запись)

Можно субд остановить, потом скопировать файлы.

Пока ты делаешь дамп кто-то пишет в бд и твой дамп становится неконсистентным.

Всё зависит от $subj. Какие-то субд умеют изолировать состояние бд и сделать дамп, какие-то нет. Кто-то делает ИС нормально и там даже на всратых субд можно на лету делать бекап базы, а где-то сделано через задницу, постоянные апдейты, удаления и единственный вариант - остановка.

Транзакции отменили?

Спасибо. Поизучал. Этой утилите для работы нужен аппаратный RAID с поддержкой снапшотов. У меня на виртуалке нету такого.

Этой утилите для работы нужен аппаратный RAID с поддержкой снапшотов

Шта? Причём тут аппаратный RAID, тем более, с поддержкой снапшотов?

FSFREEZE(8)                  System Administration                 FSFREEZE(8)

NAME
       fsfreeze - suspend access to a filesystem (Ext3/4, ReiserFS, JFS, XFS)

SYNOPSIS
       fsfreeze --freeze|--unfreeze mountpoint

DESCRIPTION
       fsfreeze suspends or resumes access to a filesystem.

       fsfreeze halts any new access to the filesystem and creates a stable
       image on disk. fsfreeze is intended to be used with hardware RAID
       devices that support the creation of snapshots.

Не верить глазам своим?

не верь

она спокойно работает даже на /dev/sda

но все пишущие процессы зависнут пока не отпустишь фс

Где-то они так работают, где-то нет.

Не верь. Ну или проверь сам.

Кто-то все еще использует dump? Его же сам Торвальдс обосрал больше 20 лет назад:

Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playing
russian roulette with their backups.  It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

Пять из шести учёных доказали безопасность русской рулетки. Шестой, пораскинув мозгами, доказал обратное.

Ну т.е. вы просто в небо? Или проверили прежде чем вбрасывать? Я то проверил.

Пять из шести учёных доказали безопасность русской рулетки. Шестой, пораскинув мозгами, доказал обратное.

У вас в барабане два патрона вместо одного:

1. вы собираетесь делать дамп не зная что такое консистентность (согласованность) данных в БД

2. вы спрашиваете совета у «специалистов» на ЛОРе

Также, я вижу некоторые нестыковки в вашей истории. Вы пишите о том что вам нужно перенести сервера в другое место. Но при этом хотите делать дамп с работающей системы и переносить оставляя ее работающей. Те все данные записанные в БД после дампа не попадут в перенос. Вам не кажется это несколько странным?

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

В таком случае гуглите примеры вызова mongodump и mongorestore. Этого будет достаточно, только убедитесь что вам хватает места на диске для дампа.

Естественно, придется углубиться в детали. Что за база данных, что для нее есть и что она поддерживается.

Но в целом автор топика явно страдает ерундой и рискует данными в угоду придуманным требованиям по аптайму.

это он малость про другое

чисто технически рут обычно нормально переживает dump/restore на живую (я делал это не 1 раз IRL), но нужно отчётливо представлять себе побочные эффекты (изменённые во время сохранения файлы типа /var/log/messages и т.п.).

на деле dump/restore только для рута и нужен.
остальное проще, надёжнее и эффективнее с помощью tar и т.п. перелить.
а сервер совсем-совсем нельзя остановить?
а то на холодную точно спокойно можно что угодно переливать.
раздел 1? ФС какая?

ещё фишка - restore можно скомандовать восстанавливать не всё, а по спику - просто исключаешь файлы базы или просто стираешь. их отдельно обрабатываешь, инитишь базу по-новой, и залвиаешь туда дамп, сделанный родными средствами БД.

Однозначно. При наличии исходного массива данных можно рсинком итеративно довести изменения и так переносить все уменьшающуюся дельту, пока копия не сойдутся. В проксмоксе в две итерации переносят и даунтайм на второй рсинк всего несколько секунд. Плюс оригинал остаётся.