Удалённое изменение дистрибутива Linux с сохранением данных

Удалённое изменение дистрибутива Linux с сохранением данных

У меня есть безголовая Fedora 15 (без GUI) коробка. Со следующей структурой разделов:

$ df -T -h
Filesystem    Type    Size  Used Avail Use% Mounted on
rootfs      rootfs     49G  2.8G   46G   6% /
udev      devtmpfs    1.7G  4.0K  1.7G   1% /dev
tmpfs        tmpfs    1.7G     0  1.7G   0% /dev/shm
tmpfs        tmpfs    1.7G  604K  1.7G   1% /run
/dev/sda1     ext4     49G  2.8G   46G   6% /
tmpfs        tmpfs    1.7G     0  1.7G   0% /sys/fs/cgroup
tmpfs        tmpfs    1.7G     0  1.7G   0% /media
/dev/sda5     ext4    388G   35G  334G  10% /var
/dev/sda2     ext4     28G  1.7G   25G   7% /home

Я устал от политики Fedora Project с 12-14-месячным циклом поддержки (у них могут быть свои причины) и намерен перейти на что-то более стабильное, например Scientific Linux или CentOS. Большая часть моих данных находится в /var(MySQL, Redis и Apache Docroot) и /home.

Возможно ли перейти с Fedora на другой дистрибутив семейства RH, сохранив каталоги /var, и /homeсделать это удаленно? (В крайнем случае я готов принести с собой монитор и клавиатуру.) Если да, то какие шаги для этого нужно выполнить?

решение1

Теоретически, конечно. Теоретически можно было бы заменить Fedora box наSlackwareна месте, если вы достаточно заботитесь и не пожалейте времени, чтобы сделать это, не разрушив ничего.

Обычно считается, что это не стоит усилий.

Вы заметите, после прочтения документации CentOS/SL, что они даже не рекомендуют обновляться между основными релизами на месте, даже интерактивно на консоли. Переход с новейшей Fedora на, скажем, CentOS 6, был бы еще хуже, так как это фактическипонижение, с точки зрения функций и версий. Вы могли заметить, что часто требуется гораздо больше работы для понижения версии одного RPM, чем для его обновления; теперь поймите, что речь идет о выполнении этого примерно для тысячи RPM для довольно скромного сервера, и больше для системы с установленными наборами пакетов Desktop, Workstation или Everything.

Лучшая практика — сделать резервную копию, переустановить ОС с нуля и восстановить ее.

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

Как именно вы собираетесь делать резервное копирование и восстановление — это на самом деле куча отдельных вопросов. Например, MySQL DB, вероятно, следует резервировать более разумно, чем просто останавливать сервер и копировать необработанные файлы DB, поскольку вы, скорее всего, собираетесь понизить версию сервера вместе с изменением ОС. Вместо этого вы захотите сделать SQL-дамп. Это всего лишь один пример из нескольких, которые вы, вероятно, найдете.

Связанный контент