Перенос linux на другой диск на примере debian/ubuntu
Навеяно статьей про перенос freebsd на другой диск. Будем делать тоже самое но на linux. В linux все несколько сложнее.
Для начала нужно подсоединить новый диск и загрузится. В системе должны присутствовать 2 диска, первый с нашей системой, а второй пустой.
Второй мы можем разметить по своему усмотрению или же скопировать разметку с первого диска(если второй диск идентичен первому). Как скопировать разметку можно прочесть здесь.
Как разметить вручную думаю разберётесь сами, благо мануалов в интернете полно. После создания разметки разделы надо отформатировать примерно так.
# mkfs.ext4 /dev/sdb1
Затем примонтируем его в /mnt
# mount /dev/sdb1 /mnt
Теперь нам нужно создать дампы разделов, в данном случае нужно создать только дамп sda1. Установим утилиты dump/restore.
# apt-get install dump
И создаем дамп раздела в файл /mnt/root.img
# dump -0f /mnt/root.img /
Создание дампа в /mnt/root.img возможно когда на разделе используется менее 50% от /dev/sdb1. Иначе на разматывание дампа места не хватит. В остальных случаях нужно создавать дамп в другом месте, но не в разделе корня, чтобы дамп не мотал сам себя. Можно использовать раздел другой тачки примонтированный по sshfs, я проверял это прекрасно работает.
Переходим в /mnt и разматываем дамп.
# cd /mnt # restore -rf /mnt/root.img
Как видим раздел перенесся на /dev/sdb1. Если у нас /boot на отдельном разделе, то переносим его аналогично.
Теперь нам нужно установить загрузчик.
# grub-install –root-directory=/mnt /dev/sdb
Затем если требуется правим /mnt/etc/fstab и меню grub в /mnt/boot/grub/grub.cfg.
# nano /mnt/etc/fstab # nano /mnt/boot/grub/grub.cfg
Тут немного поясню зачем проверять и править эти файлы. У меня например в этих файлах были прописаны uuid разделов, и если мы уберем старый диск то ОС соответственно не загрузится, т.к у новых разделов у нас другие uuid. Я вместо uuid прописал реальные устройства корня и свопа /dev/sda1 и /dev/sda3. Все устройства sdb, станут у нас sda после извлечение первого диска.
Теперь выключаем тачку, отсоединяем первый диск и загружаемся с нового диска.
P.S. Утилиты dump и restore не ограничиваются переносом ОС с одного диска на другой. Таким образом можно переносить linux вообще на другую тачку с другим железом и дисками. Процедура почти такая же за небольшими изменениями.
- На первой тачке создаем дамп ОС;
- Загружаем вторую тачку с livecd;
- Размечаем и форматируем диски;
- Копируем туда дамп c первой тачки(по scp, например);
- Разворачиваем дамп с помощью restore;
- Устанавливаем загрузчик;
- Загружаемся.
Источник: https://anikin.pw/all/perenos-linux-na-drugoy-disk-na-primere-debian-ubuntu
Настройка резервного копирования с помощью Rdiff-backup на Debian/Ubuntu | Записки системного администратора
Rdiff-backup написан на Python и использует библиотеку librsync для передачи данных. Умеет копировать файлы на удаленный хост. Также можно делать бекап с удаленного хоста, но предварительно нужно установить там Rdiff-backup.
Хранит информацию об изменениях файлов (дельты) в сжатом виде, хорошо для больших файлов, позволяет экономить место на диске. Метаданные (права, даты, владелец) хранятся в отдельных файлах. Наличие конфигурационного файла не предполагается. Автоматизировать придется самому.
Запуск бекапа производится из консоли.
В качестве источника/назначения могут быть локальные файловые системы на том же сервере или удалённое копирование поверх ssh/rsync протоколов.
Например, при локальном копировании
| # rdiff-backup |
При удаленном копировании
С локального сервера на удаленный
| # rdiff-backup /etc [email protected]::/backup1/server1/etc |
C удаленного на локальный
| # rdiff-backup [email protected]::/etc /backup/server1/etc |
По-умолчанию rdiff-backup выполняет задания с уровнем детализации (verbosity) = 3. Возможные значения — от 0 до 9. 0=не выводить ничего, даже критические ошибки. 9=максимально возможный детальный лог
Можем регулировать любыми значениями от 0 до 9.
1. Установка Rdiff-backup
| # apt-get install rdiff-backup |
2. Использование Rdiff-backup
Локальное бекапирование
Например, сдеалем бекап каталога /etc/
| # rdiff-backup /etc /backup/etc |
В качестве получателя необходимо указывать либо пустой, либо несуществующий каталог, иначе rdiff-backup откажет в выполнении бекапа
Удаленное бекапирование (на удаленном сервере предварительно также необходимо установить Rdiff-backup)
Для удобства копирвоания настроим аутентификацию по SSH-ключам
| # ssh-keygen -t rsa -b 4096 |
| # ssh-copy-id -i .ssh/id_rsa.pub [email protected] |
С локального сервера на удаленный
| # rdiff-backup /etc [email protected]::/backup1/etc |
После завершения сессий архивации rdiff-backup создаёт в каталоге архива специальный файл
| rdiff-backup-data/session_statistics* |
, содержащий разнообразную статистическую информацию о результатах сессии.
Этот файл доступен для просмотра
| # cat /backup1/etc/rdiff-backup-data/session_statistics.2016-09-07T13:09:44+03:00.data |
Утилита предлагает специальную опцию —calculate-average, при помощи которой можно получить общее представление об архиве,
| # rdiff-backup –calculate-average /backup1/etc/rdiff-backup-data/session_statistics.2016-09-07T13:09:44+03:00.data |
| 123456789101112131415161718 | ————–[ Average of 1 stat files ]————–ElapsedTime 1.27 (1.27 seconds)SourceFiles 1934.0SourceFileSize 2164267.0 (2.06 MB)MirrorFiles 1.0MirrorFileSize 0.0 (0 bytes)NewFiles 1933.0NewFileSize 2164267.0 (2.06 MB)DeletedFiles 0.0DeletedFileSize 0.0 (0 bytes)ChangedFiles 1.0ChangedSourceSize 0.0 (0 bytes)ChangedMirrorSize 0.0 (0 bytes)IncrementFiles 0.0IncrementFileSize 0.0 (0 bytes)TotalDestinationSizeChange 2164267.0 (2.06 MB)Errors 0——————————————————- |
Для просмотра статистки при выполнении бекапа можно использовать опцию —print-statistics
| # rdiff-backup –print-statistics /etc [email protected]::/backup1/etc |
| 1234567891011121314151617181920 | ————–[ Session statistics ]————–StartTime 1473243157.00 (Wed Sep 7 13:12:37 2016)EndTime 1473243158.06 (Wed Sep 7 13:12:38 2016)ElapsedTime 1.06 (1.06 seconds)SourceFiles 1935SourceFileSize 2164271 (2.06 MB)MirrorFiles 1934MirrorFileSize 2164267 (2.06 MB)NewFiles 1NewFileSize 4 (4 bytes)DeletedFiles 0DeletedFileSize 0 (0 bytes)ChangedFiles 1ChangedSourceSize 0 (0 bytes)ChangedMirrorSize 0 (0 bytes)IncrementFiles 2IncrementFileSize 0 (0 bytes)TotalDestinationSizeChange 4 (4 bytes)Errors 0————————————————– |
Поскольку rdiff-backup выполняет инкрементное копирование, при регулярном архивировании часто изменявшиеся в прошлом файлы будут иметь несколько версий. Чтобы получить информацию об имеющихся в архиве инкрементах файлов/каталогов, используем ключ —list-increments:
| # rdiff-backup –list-increments /backup1/etc/ |
| Found 1 increments: increments.2016-09-07T13:11:20+03:00.dir Wed Sep 7 13:11:20 2016Current mirror: Wed Sep 7 13:12:37 2016 |
Получение списка файлов на определённый момент времени
Список всех файлов в архиве, которые в нём содержались 2 версии назад, включая также файлы, которые были удалены в последующих версиях:
| # rdiff-backup –list-at-time 2B [email protected]::/backup1/etc/ |
Аналогично, но выводит список файлов/каталогов, которые в нем содержались 1 день назад, включая также файлы, которые были удалены в течение последних суток
| # rdiff-backup –list-at-time 1D [email protected]::/backup1/etc/ |
Получение списка изменявшихся файлов Часто бывает необходимо получить список файлов, которые модифицировались за определённый промежуток времени.
Список файлов, которые менялись за последние 10 минут:
| # rdiff-backup –list-changed-since 10M [email protected]::/backup1/etc/ |
| changed .new mynewfile.txt |
Сравнение архива и текущего состояния файлов
Список всех файлов, которые были изменены в каталоге /etc с момента его последней архивации в каталог /backup1/etc на удаленный сервер 192.168.10.56
| # rdiff-backup –compare /etc [email protected]::/backup1/etc/ |
| No changes found. Directory matches archive data. |
3. Восстановление бекапа
Поскольку rdiff-backup хранит файлы в открытом/неизменном, то в случае необходимости восстановить файл-каталог можно просто скопировать его обратно из архива обычной командой cp (если бекап локального каталога выполнялся локально)
Для восстановления из удаленного сервера используем команду rdiff-backup
Восстановить(-r) файл /etc/newfile.txt из последней версии архива(now),расположенного на удаленной системе(192.168.10.56 в каталоге /backup1/etc)
| # rdiff-backup -r now [email protected]::/backup1/etc/newfile.txt /etc/newfile.txt |
| Fatal Error: Restore target /etc/newfile.txt already exists, specify –force to overwrite. |
Т.к файл на приемнике уже существует, то rdiff-backup отказывается его заменять и предлагает использовать опцию —force для принудительной перезаписи существующего файла
| # rdiff-backup –force -r now [email protected]::/backup1/etc/newfile.txt /etc/newfile.txt |
Если необходимо восстановить определенную копию файла newfile.txt, а не последнюю, то для начала просмотрим существующие версии файла
| # rdiff-backup –list-increments [email protected]::/backup1/etc/newfile.txt |
| Found 1 increments: newfile.txt.2016-09-07T13:12:37+03:00.diff.gz Wed Sep 7 13:12:37 2016Current mirror: Wed Sep 7 13:36:15 2016 |
Восстановим нужную версию файла, указав нужную версию файла из каталога increments
| # rdiff-backup –force 192.168.10.56::/backup1/etc/rdiff-backup-data/increments/newfile.txt.2016-09-07T13:12:37+03:00.diff.gz /etc/newfile.txt |
Если необходимо восстановить файл на одну версию назад(старше)
| # rdiff-backup –force -r 1B 192.168.10.56::/backup1/etc/newfile.txt /etc/newfile.txt |
Или через указание даты
| # rdiff-backup –force -r 2016-09-07T13:12:37+03:00 192.168.10.56::/backup1/etc/newfile.txt /etc/newfile.txt |
4. Удаление старых версий Для удаления бекапов старше определенного времени используется опция —remove-older-than.
Например, удаляем бекапы старше одного месяца:
| # rdiff-backup –remove-older-than 1M 192.168.10.56::/backup1/etc |
| No increments older than Mon Aug 8 14:08:36 2016 found, exiting. |
Или удаляем бекапы старше 5 сессий/версий
| # rdiff-backup –remove-older-than 5B 192.168.10.56::/backup1/etc |
| No increments older than Wed Sep 7 13:09:44 2016 found, exiting. |
5. Исключение каталогов/файлов из бекапа
Создадим бекап всей файловой системы за исключением содержимого указанных каталогов, указанных в опции —exclude
| # rdiff-backup –exclude '/tmp/*' –exclude '/proc/*' –exclude '/sys/*' –exclude '/media/*' –exclude '/mnt/*' –exclude '/var/lib/lxc/*' –exclude '/var/lib/lxcsnapshot/*' –exclude /backup / [email protected]::/backup2/server1 |
Иногда проще указать то, что нужно скопировать, вместо того, что НЕ нужно. Следующая команда скопирует, например, /usr/local/bin, пропустив при этом /usr/bin:
| # rdiff-backup –include /usr/local –exclude /usr / [email protected]::/backup2/server1 |
при множественном использовании опций ‘—include’ / ‘—exclude’ их приоритет зависит от порядка появления в команде.
rdiff-backup позволяет использовать шаблоны подобные тем, которые используются в rsync: ‘**’ эквивалентны любому пути, а ‘*’ — любому пути без завершающего слеша. Так, например, следующая команда скопирует /usr/local и /var, но пропустит всё остальное:
| # rdiff-backup –include /usr/local –include /var –exclude '**' / [email protected]::/backup2/server1 |
Кавычки нужны, поскольку большинство оболочек обрабатывают звёздочки как спецсимволы, превращая их в маски.
6. Создание скрипта для бекапа
Создадим скрипт для бекапа и добавим его в планировщик заданий cron на ежесуточное выполнение
| # mkdir /usr/local/scripts |
| # nano /usr/local/scripts/backup.sh |
| 12345678910111213141516171819202122232425262728 | #!/bin/bash# Определяем имя сервера который бекапим – используем это для создании структуры каталогов на удаленном сервереHOSTNAME=$(which hostname)HOST_NAME=$($HOSTNAME -s)RDIFF_BACKUP=$(which rdiff-backup)# Адрес Backup-сервера, на который будем бекапитьBACKUP_SERVER='192.168.10.56'# Пользователь от имени которого будем бекапить(подключаться на сервер бекапов)USER='root'# Директория на сервере бекапов в которой создаются бекапыPREFIX='/backup'# Директории которые ИСКЛЮЧАЕМ из бекапаEXCLUDE_DIR1='/proc/*'EXCLUDE_DIR2='/sys/*'EXCLUDE_DIR3='/media/*'EXCLUDE_DIR4='/mnt/*'EXCLUDE_DIR5='/tmp/*'$RDIFF_BACKUP –exclude=$EXCLUDE_DIR1<\p> –exclude=$EXCLUDE_DIR2<\p> –exclude=$EXCLUDE_DIR3<\p> –exclude=$EXCLUDE_DIR4<\p> –exclude=$EXCLUDE_DIR5 / $USER@$BACKUP_SERVER::$PREFIX/$HOST_NAME |
Выставляем бит исполнения для скрипта и добавляем его в сron
| # chmod +x /usr/local/scripts/backup.sh |
| 15 2 * * * root bash /usr/local/scripts/backup.sh |
при использовании нестандартного порта SSH при подключении к удаленному хосту указываем порт SSH в опции —remote-schema
| –remote-schema “ssh -C -p 2220 %s rdiff-backup –server” |
По умолчанию используется следующая —remote-schema
| –remote-schema “ssh -C %s rdiff-backup –server” |
| С – включение сжатия%s – имя хоста подставляется вместо %s |
Скрипт для бекапа с удаленного сервера каталога с данными
| # nano /usr/local/scripts/rdiff-backup.sh |
| 1234567891011121314151617181920212223 | #!/bin/bashRDIFF_BACKUP=$(which rdiff-backup)USER='root'DATE=”$(date +%Y-%m-%d)”LOGFILE=”/var/log/rdiff-backup.log”HOSTNAME1=”myservername”DEST_DIR1=”/home/backup/rdiff-backup/$HOSTNAME1″INCLUDE_DIR1='/var/www/data'${RDIFF_BACKUP} –remote-schema “ssh -C -p 2220 %s rdiff-backup –server” $USER@$HOSTNAME1::${INCLUDE_DIR1} ${DEST_DIR1}exitcode=$?if [ “$exitcode” -eq “0” ]then echo “Rdiff-backup $HOSTNAME1 completed successfully – $DATE” >> $LOGFILEelse echo “Rdiff-backup $HOSTNAME1 is failed – $DATE” >> $LOGFILEfi# Delete backups older 30 days${RDIFF_BACKUP} –remove-older-than 1M ${DEST_DIR1} |
Источник:
http://ashep.org/2012/rezervnoe-kopirovanie-pri-pomoshhi-rdiff-backup/#.V8_V0zW22Ul
http://ashep.org/2012/rabota-s-arxivami-rdiff-backup/#.V8_ZsTW22Ul
http://www.hilik.org.ua/rdiff-backup/
http://www.nongnu.org/rdiff-backup/examples.html
Источник: https://kamaok.org.ua/?p=2002
Перенос установленной на LVM разделе виртуальной машины KVM на другой сервер с помощью lvmsync
Данная утилита позволяет решить задачу переноса виртуальной машины с одного сервера KVM на другой, с минимальным простоем виртуальной машины, без использования общего хранилища (non-shared storadge).
Передавать мы будем весь раздел LVM, на который установлена виртуальная машина.
Ну а уменьшить время простоя нам поможет магия работы LVM snapshot, информацию о которой вы с легкостью можете найти в интернете.
Вот как выглядит перенос виртуальной машины в кратком виде:
- Делаем снимок LVM раздела.
- Передаем основной LVM раздел по сети, не останавливая нашу VM.
- Когда закончится передача основного раздела, останавливаем VM.
- Запускаем lvmsync для передачи снимка по сети. Передается не весь снимок, а только измененные блоки.
- Подготавливаем и запускаем VM на новом сервере.
В результате, при использовании lvmsync время простоя виртуальной машины будет равно времени передачи измененных блоков в снимке основного раздела.
Подробнее о работе lvmsync, и дополнительных плюшках вы можете почитать на страничке проекта.
Далее предполагается что у нас есть права sudo в системе, ssh доступ настроен по ключам, а вход под рутом запрещен.
Приступим к переносу VM:
Установка:
Для работы lvmsync нам потребуется Ruby 1.8 (or later), ssh, и dmsetup.
Скачиваем lvmsync на локальный компьютер:
wget https://github.com/mpalmer/lvmsync.git
Копируем lvmsync в root PATH, например в /usr/bin/
Подготовка удаленного сервера (server2):
1) Скачиваем и устанавливаем lvmsync.
2) Создаем LVM раздел для копируемой VM.
server2# lvcreate vg -n new-virtual -L 16G
Размер раздела должен быть равен исходному разделу (в принципе он может быть и больше исходного, но этот вариант мной не тестировался).
Подготовка локального сервера и перенос VM
Далее все команды необходимо выполнять на сервере, с которого мы хотим переместить виртуальную машину (server1).
1) Создаем definition xml:
server1# virsh dumpxml virtual > virtual.xml
2) Делаем снимок раздела:
server1# lvcreate –snapshot -L10G -n virtual-snap /dev/vg/virtual
Warning!
Обратите внимание, что размер снимка должен выбираться в зависимости от интенсивности использования VM. Т.к. все данные, пока мы переносим основной раздел, будут «сохраняться» на снимок.
И при полном заполнении снимка, он автоматически деактивируется.
3) Не останавливая VM, переносим основной раздел с помощью dd:
server1# dd if=/dev/vg/virtual bs=1M | gzip -c | pv -ptrb | ssh me@server2 “gunzip -c | sudo dd of=/dev/vg/new-virtual”
Здесь добавлено сжатие передаваемых данных гзипом, и отображение хода передачи данных с помощью pv.
4) Когда перенос будет закончен, останавливаем виртуальную машину:
server1# virsh shutdown virtual
5) И после полной остановки машины запускаем lvmsync для переноса снимка:
server1# lvmsync –stdout /dev/vg/virtual-snap | ssh me@server2 sudo lvmsync –apply – /dev/vg/new-virtual
Эта операция не только перенесет снимок на новый сервер, но и смержит его сразу с основным разделом LVM.
6) Копируем definition xml на удаленный сервер:
server1# scp virtual.xml me@server2:/home/me/new-virtual.xml
Подготовка и запуск виртуальной машины на новом сервере:
1) Изменяем definition xml, если необходимо.
2) Создаем виртуальную машину на основе xml:
server2# virsh define new-virtual.xml
3) Запускаем нашу виртуальную машину, и прописываем ее в автостарт:
server2# virsh start new-virtual
server2# virsh autostart new-virtual
Вот и все, перенос виртуальной машины закончен!
Примечания
Утилита тестировалась на Centos 6.4. Про временя переноса сказать что-либо затрудняюсь, т.к. все зависит от интенсивности работы с виртуальной машиной во время ее переноса, и, соответственно, размера снапшота.
http://www.pvsm.ru/linux/37753
Источник: http://adminunix.ru/tar-chasto-ispol-zuemy-e-klyuchi/
Инкрементальный бэкап удаленного веб сервера с Mysql с помощью rsnapshot (CentOS, RHEL) – Страница 4 из 4
Для начала установим rsnapshot на сервере бэкапов:
| backup: yum install rsync rsnapshot -yserver: yum install rsync -y |
Конфигурационный файл хранится в /etc/rsnapshot.conf. rsnapshot по сути является perl скриптом-оболочкой, которая в свою очередь работает через rsync. Внимание! rsync должен быть установлен и на клиенте и на сервере бэкапов.
Очень важный момент, что отступы в конфигурационном файле должны прописываться табами, в противном случае будет ошибка. В rsnapshot можно настроить бэкапы для разных периодов — по часам, дням, неделям, месяцам.
Довольно удобная система, где нам важно делать бэкап как актуальных данных, так и тех данных, что были сделаны месяц, год назад. Если мы настроим, что у нас хранится 5 почасовых бэкапов и 2 дневных, то если за день было сделано более 5 бэкапов — мы не сможем видеть снэпшот данных на начало дня, т.к.
у нас стоит ограничение. Однако, бэкап по дням решит эту проблему и у нас будет храниться снэпшот за прошлый и позапрошлый день. Для нас важны следующие части конфигурации:
| # All snapshots will be stored under this root directory.snapshot_root /mnt/snapshots |
Данный параметр указывает на корень в файловой системе, относительно которого будут записываться наши снэпшоты.
Параметры для ssh, в котором мы указываем файл ключа для авторизации:
| ssh_args -i /root/.ssh/backup_key_dsa |
В данном случае мы как раз настраиваем количество бэкапов для каждого вида. Далее нам нужно описать конфигурацию бэкапа:
| backup root@client:/var/www/ www_server/exclude_file /root/rsnapshot.exclude.web_serverbackup_script /usr/bin/ssh -i /root/.ssh/backup_key_dsa backup@client “/root/rsnapshot.mysql.sh” unused1/backup_script /usr/bin/scp -r -i /root/.ssh/backup_key_dsa backup@client:/tmp/rsnapshot/mysql/ /tmp/mysql_backups mysql/ |
1 строка указывает нам, что мы по scp заходим на сервер client, забираем с него папку /var/www/ и гладем ее в /mnt/snapshots/daily.0/www_server, где /mnt/snapshots/ — это указанный нами корень для снэпшотов, а daily.
0 — это тип бэкапа и его нумерация. 2 строка — т.к. у нас есть данные, которые нам не нужны в бэкапе, например — файлы логов, кэша, то мы можем исключить их.
В этой строке мы указываем файл, в котором прописаны исключения для синхронизации. Пример файла —
3 строка — мы выполняем скрипт /root/rsnapshot.mysql.sh на удаленном сервере client. unused1 — это заглушка, которую оставляем без внимания.
4 строка — мы переносим файлы дампов с удаленного сервера client по scp из папки /tmp/rsnapshot/mysql/ (эту папку мы указывали в скрипте rsnapshot.mysql.sh) в папку /tmp/mysql_backups на сервере backup, затем переносим в /mnt/snapshots/daily.0/mysql в папку снэпшотов. Сохранив файл конфигурации — его можно проверить встроенной командой:
В 3-4 строке мы указали путь к файлу, т.к. ssh_args работают только на встроенные команды, а в данном случае мы вызываем внешние команды.
Последний шаг — необходимо поставить задания в cron, при том для каждого вида бэкапа — отдельное, что логично. Редактируем файл /etc/cron.d/rsnapshot, заносим в него:
| 0 */4 * * * root /usr/bin/rsnapshot hourly30 3 * * * root /usr/bin/rsnapshot daily0 3 * * 1 root /usr/bin/rsnapshot weekly30 2 1 * * root /usr/bin/rsnapshot monthly |
Как мы видим — бэкап запускается каждые 4 часа, каждый день в 3:30, каждый понедельник в 3:00, каждый 1 день месяца в 2:30.Если нам какой-то из видов бэкапов не нужен — просто комментируем необходимую строчку. Напоследок несколько полезных команд — Проверка реально занимаемого места снэпшотами:
Вывод процесса (команд) бэкапа без выполнения:
Ручной запуск обновления:
Тестирование конфигурации:
Источник: https://ittricks.ru/administrirovanie/linux/681/inkrementalnyj-bekap-udalennogo-veb-servera-s-mysql-s-pomoshhyu-rsnapshot-na-centos/4
Veeam Agent for Linux. Настройка бекапа физического сервера
Доброго дня, читатель. В одной из предыдущих заметок, речь шла о бекапе физического сервера под Windows. Сегодня речь пойдет о настройке бекапа физического сервера (или VPS) с операционной системой Linux (Centos, Ubuntu, etc.) в общий репозиторий Veeam Backup & Replication.
Ситуация следующая, у вас имеется сервер на Linux, железный или виртуальный, который находится не в инфраструктуре VMware, например. И его нужно бекапить.
На помощь приходит Veeam Agent for Linux, с помощью которого можем делать бекап в общий репозиторий Veeam или же в другое место по желанию. Я делаю бекап именно в общий репозиторий Veeam.
Установка самого агента Veeam Agent for Linux не должна вызвать особого труда, все описано здесь, под требуемую ОС. Так же для возможности восстановления из бекапа, вам понадобится Veeam Recovery Media, по ссылке описание и страница загрузки. Отталкиваемся от того, что агент установлен.
Перейдем к самой настройки Veeam Agent for Linux
После установки агенга запускаем его командой из под root’а:
veeam
Попадаем в консоль настройки Veeam Agent for Linux. Если у вас есть лицензия вводим ее, если нету, жмем “No” и продолжаем настройку в бесплатном режиме
Даем имя вашему бекапу и жмем “Next”
На данном этапе выбираем уровень бекапа, который мы будем делать с помощью Veeam Agent for Linux. Есть три варианта: полностью весь сервер или виртуальную машину, уровень бекапа отдельных разделов, бекап файлов вашего сервера на Linux. Я предпочитаю первый вариант, так как из него можно восстановить и отдельные разделы, и отдельные файлы, если такое потребуется. “Next”
И снова три варианта. Либо бекап храним локально, на этом же сервере (не рекомендую), либо в расшареной папке (где-то не здесь), либо в общем репозитории Veeam. Решать вам, я же храню это все в общем репозитории. Далее
Подключение к репозиторию Veeam
На данном этапе вводим ip адрес вашего репозитория Veeam. Тут есть два варианта. Если ваш сервер Linux и репозиторий Veeam в одной локальной сети, то вводим локальный адрес репозитория. Если же сервер с репозиторием имеет “белый” внешний адрес и находится в разных сетях с сервером, то вводим этот внешний адрес. Важно о портах. Какие и где открыть, описано тут.
Сложностей не должно вызывать. Порт указываем 10002. Логин, домен и пароль учетной записи, для которой разрешено подключение к репозиторию Veeam. Разрешить или запретить подключение можно в свойствах самого репозитория через консоль Veeam Backup & Replication — Agent Permissions.
Скрин ниже, выбираем “Запретить для всех”, “Разрешить для всех” или же указываете конкретные учетные записи для разрешения.
Дальше выбираем какой именно репозиторий использовать для хранения бекапа, количество точек восстановления, задаем расписание и, если все хорошо, запускаем создание бекапа. Ждем некоторое время. Смотреть за процессом создания и за возможными ошибками можно нажав “Enter” по самому заданию.
Если все прошло успешно, бекап создался. Восстановить разделы, файлы или полностью весь сервер как есть можно, для этого нужно скачать Veeam Recovery Media в формате .iso под вашу ОС, загрузиться с него, подключиться к репозиторию Veeam и восстановитьнужное. Если у вас возникают сложности, пишите в комментарии, постараюсь ответить.
Источник: http://adminexperience.pp.ua/2018/05/01/veeam-agent-for-linux/
Миграция сервера Linux в 7 шагов
Миграция сервера Linux в 7 шагов, так что вам не нужно будет делать новую установку, если вы перемещаете сервер к новому провайдеру.
Вы действительно можете сделать больше денег каждый месяц, если вы перейдете к более дешевому и качественному поставщику. Вы можете это сделать за 7 простых шагов.
Недавно мы мигрировали целый сервер Linux Fedora Core 11 и он отнял у нас больше времени, чем первоначально ожидалось, поэтому мы написали этот пост, потому что не нашли помощи в Интернете. Если это не поможет вам, не стесняйтесь писать в комментариях.
Шаг 1 – Подготовительный этап перед миграцией
- Если вы используете 64 – битное программное обеспечение, то мигрировать на 32 -битный сервер не получится.
- Проверьте, сколько пропускной способности сети используется. Проверьте, хватает ли пакета трафика у нового поставщика достаточно для текущей месячной пропускной способности.
- Не ведитесь на “Вы можете поместить свой сервер в VMware VM и оплатить услуги по управлению каждый месяц. Вы просто должны выполнить скрипт на сервере”. Это выглядит очень легко и это действительно так, но вы будете платить больше каждый месяц за то, что вы не будете использовать.
Шаг 2 – Выбор нового поставщика
Давайте начнем с того, что свяжемся с несколькими поставщиками и выберем оптимальный вариант.
Это очень важно, потому что вам нужно купить новый сервер от поставщика, который имеет панель управления для Вас, чтобы была возможность перезагрузить сервер, в идеале имеет консоль KVM, так что вы можете изменить настройки BIOS и контролировать все, и по крайней мере имеет 2 диска.
Если вы выбираете для решения KVM, вы можете установить миграцию сервера через LIVE CD Linux , который ваш провайдер установит для вас.
Если вы не хотите такого рода проблем, просто попросите новую установку любого дистрибутива (на основе Ubuntu или Debian), который вы установите на вторичном диске, а затем вы будете делать его первичным.
Шаг 3 – Подготовьте целевой сервер для получения данных
Вы должны иметь готовым новый сервер для получения данных от вашего первичного сервера.
Если вы используете обычный дистрибутив Linux (Finnix , Fedora , Ubuntu , …) вы можете создать все разделы с помощью cfdisk, а затем следовать ниже команды :
/* * Imagine: * /dev/sda1 – boot (ext2) * /dev/sda2 – swap * /dev/sda3 – root filesystem where your OS is installed */# mkdir /mnt/root
# mount /dev/sda3 /mnt/root
# mount /dev/sda1 /mnt/root/boot
# mount –bind /dev /mnt/root/dev
# mount –bind /sys /mnt/root/sys
# mount –bind /proc /mnt/root/proc
# chroot /mnt/root
Примечание: Вам потребуется GNU-версия netcat на сервере назначения. Если в вашем дистрибутиве его нет, то попробуйте установить его.
Затем на сервере назначения:
cd /mnt/root
netcat -vv -l -p 31337|tar vxfzp –
Проверьте безопасность
Перемещение сервера является прекрасной возможностью получить взлом очень опытного хакера. Вы должны рассмотреть безопасность связи сети между двумя серверами является, в противном случае вы должны использовать альтернативу Netcat для передачи файлов, такие как scp.
Шаг 5 – Резервное копирование все с исходного сервера
Проверьте доступные диски сервера:
$ fdisk -l
Проверьте разделы, так что вы можете скопировать его на сервер назначения (измените диск /dev/sda, который вы хотите увидеть):
$ cfdisk /dev/sda
Используйте tar и untar для диска по сети. Если диск на вашем исходном сервере больше, чем диск на вашем целевом сервере, и у вас еще есть достаточно места на целевом сервере то можете сжать данные:
/* * Я использовал nc здесь, но вы можете использовать netcat, если у вас он установлен */# tar -cvpzf – –exclude=/mnt/ –one-file-system / | nc -vv your_destination_server_ip 31337
Шаг 6 – Новые конфигурации
Есть несколько вещей, которые будут отличаться в новом сервере
1) Диски UUID
– Либо вы идете в /boot/grub/menu.lst и /etc/fstab и измените UUID для новых дисков.
– вы можете также изменить UUID на новых дисках до тех же самых старых на ваших дисках:
На старом сервере: # blkid /dev/sdaX (change X for 1, 2 or 3…)
На новом сервере:
# tune2fs -U UUID-you-got-from-the-blkid-in-the-old-server /dev/sdaX (change X for 1, 2 or 3…)
Своп файл
# mkswap -U UUID-you-got-from-blkid-in-the-old-server /dev/sdaX (change X for 1, 2 or 3…)
2) драйверы должны быть загружены
Если у вас есть стандартное ядро, вероятно, все драйвера будут доступны, модулем. Если вам необходимо устранить его позже, убедитесь, что вы сохранили список:
lsmod
Также имейте в виду , что разные версии ядра могут иметь разные имена модулей …
Заметка: у нас была проблема переноса ядра Fedora 11, потому что в ядре не было драйвера, работающего на новом жестком диске. Так что мне пришлось зайти на kernel.org и скомпилировать новое ядро вручную.
3) Конфигурация сети
Это действительно зависит от вашего дистрибутива, но вы, вероятно, можно настроить сеть довольно легко.
В Fedora :
# system-config-network
4) IP – адрес конфигурации в /etc
Постарайтесь запомнить и найти какие – либо жёстко прописанные конфигурации IP:
grep -r “your-old-IP-address” /etc
Шаг 7 – Итоги
Вариант 1
Если вы использовали опцию консоли KVM, вы можете просто изменить BIOS на новом сервере, чтобы загрузить новую систему.
Вариант 2
Если вы имеете 2 диска и система установлена на втором диске, попросите поставщика, чтобы он сделал второй основным диском или просто измените /boot/grub/menu.lst , чтобы загрузить на этот диск .
Источник: https://andreyex.ru/operacionnaya-sistema-linux/migraciya-servera-linux-v-7-shagov/
Резервное копирование Ubuntu
Резервное копирование системы очень важно, поскольку если у вас есть резервная копия всех файлов, настроек или даже системы полностью, то вы можете ее восстановить в случае возникновения проблем. Несмотря на стабильность Linux, эта система может ломаться, например, после обновления или когда вы экспериментировали и сделали что-то не так.
Если вы делаете резервное копирование Ubuntu, то потом сможете все очень просто восстановить, даже если система была почти убита.
Уже существует множество программ для создания резервных копий как файлов, так и всего диска, одна из самых популярных из них – это CloneZilla. Но мы не будем их сегодня рассматривать.
В этой статье мы поговорим о том, как выполнить резервное копирование системы без сторонних программ, с помощью системных команд. Это может быть полезнее в некоторых случаях.
Резервное копирование Ununtu
Рассмотрим самые распространенные способы копирования среди администраторов и обычных пользователей.
Способ 1. Список пакетов
Самый простой способ резервного копирования Ubuntu, кстати, именно эту возможность использует MintBackup в LinuxMint, это получение списка всех установленных пакетов. Да, тут вы не сохраните всю конфигурацию, зато сможете очень быстро восстановить все установленные программы.
Если учесть, что большинство конфигурационных файлов находятся в домашней папке пользователя, а она не стирается при переустановке, то остальные файлы не такая уже большая проблема. А такая резервная копия будет занимать всего несколько килобайт. Для выполнения резервной копии наберите такую команду:
dpkg –get-selections | grep -v deinstall > backup.txt
Далее, скопируйте полученный файл в надежное место. Когда система сломается, переустановите ее с установочного носителя, а затем просто выполните команды:
sudo dpkg –set-selections < backup.txt
sudo apt-get -y update
$ sudo apt-get dselect-upgrade
Файл со списком пакетов нужно поместить в текущую папку. Таким образом, вы очень быстро вернете все ранее установленные программы с минимальными затратами времени и в то же время получите чистую систему.
Способ 2. Создание архива
Резервное копирование таким способом более надежно, поскольку вы не просто создаете список установленных программ, а делаете архив из всей файловой системе. Фактически, вы можете потом развернуть этот архив на любой машине и получить полноценную операционную систему после настройки драйверов.
Таким способом часто создаются резервные копии систем на серверах и для него достаточно просто использовать утилиту tar и не нужны сторонние программы. Для создания архива используйте такую команду:
sudo tar czf /backup.tar.gz –exclude=/backup.tar.gz –exclude=/home –exclude=/media –exclude=/dev –exclude=/mnt –exclude=/proc –exclude=/sys –exclude=/tmp /
В этой команде все достаточно просто несмотря на ее запутанность. Опция c означает, что нужно создать архив (Create), z – включает сжатие Gzip. Затем с помощью опции -f мы указываем файл, в который нужно сохранить результат.
Затем с помощью серии опций –exclude мы исключаем из архива сам файл архива, домашний каталог и директории с виртуальными файловыми системами. В самом конце указываем папку, с которой стоит начать сбор данных – /. Вот и все.
Процесс займет очень много времени, но когда он завершится, вы получите полную резервную копию системы в корневом каталоге.
Если система повреждена, вам нужно загрузиться с LiveCD/USB, и примонтировать корневой каталог в /mnt/. Затем подключите носитель с резервной копией и выполните команду для распаковки:
sudo tar xf /run/media/имя_носителя/backup.tar.gz -C /mnt
Команда быстро распакует все, что было сохранено и вам останется только перезагрузить компьютер, чтобы вернуться к своей основной системе. Здесь не восстанавливается только загрузчик, восстановить Grub нужно отдельно если он был поврежден.
Способ 3. Резервное копирование в rsync
Этот способ очень похож на второй, но здесь архив не создается, а данные просто переносятся в другую папку. Это может более полезно при простом копировании операционной системы в другое место. Команда выглядит вот так:
rsync -aAXv –exclude={“/dev/*”,”/proc/*”,”/sys/*”,”/tmp/*”,”/run/*”,”/mnt/*”,”/media/*”,”/lost+found”} / /папка/назначения
Набор опций -aAX включают передачу в режиме архива, что гарантирует полное копирование символических ссылок, устройств, разрешений и расширенных атрибутов, при условии, что их поддерживает целевая файловая система. Опция –exclude, как и раньше, исключает из копии виртуальные файловые системы.
После завершения копирования вам останется отредактировать /etc/fstab и заменить в нем адрес корневого раздела на новый. А также создать новый конфигурационный файл для загрузчика, автоматически или вручную.
Способ 4. Создание образа раздела
Команда dd linux позволяет создать полную копию раздела или даже всего диска. Это самый надежный, но в то же время потребляющий большое количество памяти способ выполнить резервное копирование системы Ubuntu. Утилита просто переносит весь диск по одному байту в образ. Команда выглядит вот так:
sudo dd if=/dev/sda4 of=~/backup.img
Здесь /dev/sda4 – это ваш корневой раздел. После завершения выполнения команды вы получите готовый образ, затем, чтобы восстановить систему из этой копии достаточно поменять опции местами и указать путь к файлу копии:
sudo dd if=~/backup.img of=/dev/sda4
Правда, процесс может занять достаточно много времени, в зависимости от скорости работы вашего диска.
Способ 5. Создание Squashfs образа
Преимущество Squashfs в том, что это полноценная файловая система в одном файле, которую можно очень быстро примонтировать и быстро извлечь нужные файлы. Кроме того, файловую систему можно открыть привычными менеджерами архивов. Для создания образа со всей системы используйте:
sudo mksquashfs / /root-backup.sqsh -e root-backup.sqsh home media dev run mnt proc sys tmp
Теперь, чтобы примонтировать созданный образ будет достаточно набрать такую команду:
sudo mount /root-backup.sqsh /mnt/ -t squashfs -o loop
А уже отсюда вы можете извлечь любой файл или перенести все это в реальную файловую систему с помощью cp -p.
Выводы
Резервное копирование Ubuntu 16.04 очень важно для поддержания вашей операционной системы в нормальном состоянии. В случае любой неожиданной ситуации вы сможете все восстановить. Если вас интересуют графические программы для бэкапа, вы можете попробовать remastersys или timeshift. Надеюсь, эта информация была полезной для вас.
(14
Источник: https://losst.ru/rezervnoe-kopirovanie-ubuntu
Знакомство с Veeam Agent for Linux
Как вы, возможно, уже знаете, в недалеком будущем увидит свет наш новый продукт — Veeam Agent for Linux. И уже сейчас все желающие могут оценить это решение в ходе анонсированной программы бета-тестирования.
Чтобы получить доступ к бета-версии, нужно зарегистрироваться здесь, и вы получите на email ссылку для скачивания.
Обратите внимание, что период бета-тестирования закончится 1 сентября 2016 года – затем вы сможете установить уже релизную версию.
Итак, что же умеет бета? За ответом добро пожаловать под кат.
Veeam Agent for Linux — это наше новое бесплатное решение для резервного копирования машин под управлением Linux. Его основные характеристики:
- Может использоваться как для виртуальных, так и для физических машин.
- Работает с машинами семейств Debian и RedHat. Доступен в виде пакетов RPM и DEB.
- Поддерживаются версии ядра Linux, начиная с 2.6.32 (т е. даже если у вас очень старенькая инсталляция, то и она будет поддержана при условии, что у вас стоит официальное ядро для данного дистрибутива).
- Работает с 32-битной и 64-битной архитектурой.
Решение включает в себя следующие компоненты:
- Veeam Agent for Linux Service – компонент, отвечающий за работу со всеми задачами и необходимыми ресурсами. Регистрируется как обычный сервис, автоматически стартует при старте ОС и работает в фоновом режиме.
- Veeam Agent for Linux Job Manager – процесс, который запускается вышеназванным сервисом для каждой сессии задания резервного копирования и отвечает за ее работу.
- Veeam Agent – это, собственно, рабочая лошадка, которая выполняет операции передачи данных: во время бэкапа копирует их в репозиторий, а во время восстановления – наоборот, а также выполняет дедупликацию, компрессию, и т.д.
- Veeam Agent for Linux Driver – модуль ядра Linux, который отвечает за создание снапшотов томов вашей машины.
- SQLite database engine — используется для хранения конфигурации; если у вас его нет – то поставится в процессе установки продукта.
Veeam Agent for Linux умеет выполнять резервное копирование на уровне образа, работая внутри гостевой ОС, причем можно делать бэкапы на уровне томов и файлов. Для создания инкрементальных резервных копий нами был разработан специальный драйвер, который отслеживает измененные блоки (его модуль динамически подгружается в ядро).
Читателей, вероятно, порадует, что этот модуль поставляется в виде исходного кода.
Поскольку версий ядра великое множество, то мы решили не пытаться написать и скомпилировать бинарную версию модуля для каждой из них – в итоге вполне могло оказаться, что на какой-то из версий что-то не поддерживается, и соответствующая часть пользователей не сможет использовать решение.
Поэтому мы решили пойти по традиционному для Linux-сообщества пути – поставлять исходный код и компилировать модуль в процессе установки продукта, уже конкретно для той версии ядра, с которой ему предстоит работать.
Пользователю не придется ничего компилировать вручную – все необходимые операции выполнит менеджер пакетов вашего дистрибутива: проверит наличие необходимых зависимостей, выдаст список недостающих, чтобы вы могли все поправить, и в ходе инсталляции автоматически скомпилирует и установит наш модуль.
Выполняем установку
Для работы решения необходимо наличие пакета Dynamic Kernel Module Support (DKMS), который требуется для компиляции модуля ядра, а также пакета LVM2, который требуется для поддержки операции с томами LVM. Если их нет на машине, то установите их – к примеру, DKMS на CentOS можно поставить из дополнительного репозитория EPEL.
После того, как прошла установка первого компонента, можно переходить к установке собственно Veeam Agent for Linux (для установки понадобятся права root):
Агент Veeam Agent for Linux устанавливается в виде сервиса, с которым затем можно работать, применяя команду veeamconfig. Для просмотра списка ее опций после команды veeamconfig введите –help. Ну и затем можно переходить уже непосредственно к работе – а там уже практически все понятно и без подсказок, но мы все же вкратце рассмотрим сначала процесс бэкапа.
Приступаем к резервному копированию
Поскольку среди пользователей Linux есть как продвинутые, так и начинающие, то мы в дополнение к командной строке предлагаем простенький графический интерфейс. Для его запуска используется командная строка – в ней вводим команду veeam. На экране появится GUI с приветственным сообщением и кнопками меню:
Чтобы создать новое задание резервного копирования, нажимаем C (Configure). Проходим по шагам мастера:
- Вводим имя, которое хотим дать заданию.
- На шаге Backup mode выбираем, хотим ли мы бэкапить всю машину (Entire machine), какой-либо том (Volume level backup) или отдельные файлы и папки (File level backup):
- Затем указываем тип репозитория (Destination Location), куда будут сохраняться резервные копии. Если репозитория у нас еще нет, то мастер попросит его создать. В качестве репозитория поддерживаются:
- устройства с прямым подключением (USB, eSATA, FС и т.п.)
- сетевые файловые системы NFS, SMB (CIFS)
- локальное устройство хранения (не рекомендуется)
В данном примере в качестве репозитория выбирается папка NFS с общим доступом:
- Тут же можно указать, сколько точек восстановления (Restore points) должно храниться в репозитории – по умолчанию 14.
- Затем можно настроить расписание (Schedule) для нашего задания, указав, с какой периодичностью оно будет запускаться.
После того, как все настройки сделаны, мастер предложит вам запустить задание сразу же. Если вы еще раз хотите пройтись по настройкам и, возможно, что-то поменять, можно либо вернуться к предыдущему шагу, нажав Prev, либо, если вы уже нажали Finish и вернулись в главное меню, нажать C.
Для запуска задания из главного меню нажмите S.
Если же вы захотите запустить задание в какой-то момент по требованию, то к вашим услугам соответствующая команда:
veeamconfig job start –name “BackupJob1”
В ходе выполнения задания по нажатию Enter можно посмотреть, что как идет и что пишется в лог:
Наше задание успешно отработало, и на экране появилась соответствующая информация в поле Status:
В репозитории на NFS-сервере теперь лежат файлы резервной копии (.VBK и .VBM), поименованные согласно названию задания и времени создания:
Имея резервную копию, можно посмотреть, как Veeam Agent for Linux умеет выполнять восстановление Linux-сервера на уровне файла, тома, или же вообще «на голое железо» — но об этом в следующем посте.
Полезные ссылки
Источник: http://www.pvsm.ru/besplatno/159328
Отличия Linux – Сравнение Debian, Ubuntu, CentOS » Администрирование серверов
Задавшись вопросом, какой дистрибутив выбрать под вновь созревшие нужны, в очередной раз натыкаюсь на ответ: «Что лучше знаете — то и ставьте!» И только перелопатив достаточно весомый объем информации можно получить несколько проясненную картину. В силу сложившихся обстоятельств в моем кругу выбора оказались три дистрибутива: Debian, Ubuntu и CentOS. Что ж, попробуем разобраться что к чему.
Как известно Linux — свободная операционная система с открытым исходным кодом. Отсюда и основная причина такого многообразия образов. Да, есть и коммерческие версии. Покупая такой продукт, вы платите за брендовые пакеты и поддержку, но никак не за саму операционную систему.
Именно этим руководствовалась компания Red Hat, когда под своей крышей организовала распространение образа CentOS Linux, и предложила его всем желающим пользоваться бесплатно решениями класса Энтерпрайз. По сути, на сегодняшний день сообщество CentOS — это сотрудники компании Red Hat.
Дистрибутив CentOS полностью совместим с дистрибутивом от RHEL, а техническая разница состоит только в присутствии торгового знака и дизайнерской работы.
Проект стартовал в марте 2004 и на данный момент является одним из самых популярных серверных решений за счет высокой стабильности и совместимости.
Проект Debian несколько старше. Он был основан в августе 1993 и позиционировался как полностью некоммерческий проект. Не смотря на мнения скептиков, система до сих пор живет и процветает. По мнению автора, внимание к проекту все еще не стихает, прежде всего, из-за философии развития, большого объема бесплатного ПО и стабильного ядра.
Система Ubuntu является родственницей Debian, скорее даже дочерью. Появилась она на свет в июле 2005 года благодаря компании Canonical, которая и по сей день финансирует и контролирует развитие проекта.
Взгляды компании Canonical на развитие системы, в отличие от многих других последователей Debian, осталась верны философии распространения свободного ПО, а также весьма лояльны к критике и дополнениям.
Благодаря этому в настоящее время проект активно развивается и поддерживается сообществом.
В целом для управления любой операционной системой (не только *nix) требуется очень схожий набор знаний: работа с файловой системой, сетевыми подключениями, сервисами или демонами, пакетами прикладных программ.
Говоря о семействе Linux, конечно же, подразумеваем кучу конфигурационных файлов, командную строку (хотя — не обязательно), базовую структуру папок в корне. Однако в каждом из дистрибутивов есть свои тонкости и нюансы.
Например: всем известный «BIND», занимающийся разрешением имен в ip адреса в CentOS называется «named», а веб-сервер «appache2» из Debian и Ubuntu трансформировался в «httpd» в CentOS.
К слову сказать, заготовки структуры папок и файлов по умолчанию для appache в ubuntu скорее напоминают конфигурацию для большого хостера, а то время как базовая конфигурация веб-сервера в CentOS располагает к размещению одного корпоративного сайта и не имеет такой вереницы конфиг-файлов.
Одно в другое, конечно же, трансформируемо, но не идентично. Подобные вещи наблюдаются и в работе с командами: например, при работе с репозитариями Debian использует apt-get, в то время как в CentOS мы пользуемся yum. Суть одна и та же, но неопытного линуксовода такой зоопарк команд часто вводит в замешательство.
- Поддерживаемое железо, используемые пакеты и версии
Итак, становится резонный вопрос: что же выбрать? (Особенно, если Вам все равно с какой системой начинать знакомство.) Автор рекомендует хорошенько детально подумать, под какие задачи вы будете использовать сервер, и какие ресурсы вы для этого имеете.
Если у Вас есть физическое оборудование, которое вы предполагаете использовать в своем проекте, в первую очередь необходимо проверить его в списке поддерживаемого оборудования для каждого из дистрибутивов.
Исходя из опыта, Debian имеет меньше аппаратных проблем, чем CentOS, не смотря на то, что корпоративный дистрибутив постоянно расширяет горизонты поддерживаемого аппаратного обеспечения. Далее детально рассматриваем требуемое ПО и его версии.
Стандартные репозитарии CentOS достаточно скудны, поэтому в обслуживании (к примеру), вероятно, будет проще использовать Debian и поставить уже собранный пакет, чем собирать его руками (а в будущем возможно еще и пересобирать при обновлении) для CentOS.
И даже не смотря на то, что Ubuntu использует репозитарии Debian, из-за разницы в подходах к классификации ПО удобно будет использовать Ubuntu, бегущую впереди всех по скорости обновления пакетов. Однако не забывайте, что более новый пакет не всегда гарантирует стабильность работы. В этом вопросе решать Вам. Автор предпочитает балансировать где-то посередине между новыми возможностями и проверенными, надежными решениями.
И на закуску о версиях. Ниже предлагается сравнительная таблица релизов самих дистрибутивов. Выводы делайте самостоятельно.
| Продукт | версия | дата выхода | кодовое имя |
| Debian | 8.0 | апрель 2015 года | Jessie |
| 7.0 | май 2013 года | Wheezy | |
| 6.0 | февраль 2011 года | Squeeze | |
| 5.0 | февраль 2009 года | Lenny | |
| 4.0 | апрель 2007 года | Etch | |
| Ubuntu | 16.04 LTS | 21 апрель 2016 года | Xenial Xerus |
| 14.04 LTS | 17 апреля 2014 года | Trusty Tahr | |
| 12.04 LTS | 26 апреля 2012 года | Precise Pangolin | |
| 10.04 LTS | 29 апреля 2010 года | Lucid Lynx | |
| 8.04 LTS | 24 апреля 2008 года | Hardy Heron | |
| CentOS | 7 | 7 июля 2014 | |
| 6 | 20 июля 2011 | ||
| 5 | 12 апреля 2007 | ||
| 4 | 9 марта 2005 | ||
| 3 | 5 января 2001 |
- Установка. Есть ли отличия на самом деле?
На необъятных просторах Интернет есть масса заявлений о том, что установка одного образа отличается от установки другого, для кого-то обилие настроек кажется преимуществом, а для кого-то это сильно усложняет задачу.
В реалиях нашей жизни установка сервера крайне маловероятно будет доверена блондинке-секретарше, а специалист, выполняющий роль администратора все же должен иметь базовые знания о файловых системах и разметке диска, сетевых настройках, загрузчиках и устанавливаемых ролях сервера.
Поэтому установка любого из дистрибутивов не должна вызвать особых проблем. У каждой из систем есть GUI Installation mode, оценка удобства которого, впрочем, дело также достаточно субъективное.
Из различий стоит отметить, что Debian имеет наиболее скудный набор преднастроенных ролей, однако насколько это важно непосредственно для Вас, решать не автору.
- Безопасность: root, SELinux и другие страшные слова.
Ещё в процессе установки Ubuntu можно заметить ее отличительную особенность.
Система не предполагает использование учетной записи «root», в место этого используется утилита «sudo», повышающая права пользователя до root’a, если у пользователя, конечно, есть такое привилегии.
По мнению автора, такой подход аналогичен с User Account Control от Microsoft. Он однозначно повышает уровень безопасности и полезен при эксплуатации, хотя на первый взгляд усложняет процессы администрирования.
Системы мандатного доступа приложений к ресурсам системы есть во всех сравниваемых системах.
CentOS успешно использует SELinux, в то время как для Ubuntu разработан AppArmor, который также при необходимости успешно используется на Debian.
Что из них лучше и вообще нужно ли их использовать и в каких случаях — это большая тема отдельной статьи, поэтому сейчас останавливаться на этом подробно не стоит.
- Потребление ресурсов и нагрузочное тестирование
Минимальные системные требования к ресурсам приведены в таблице ниже:
| Memory (minimal) | HDD (minimal) | |
| Debian | 128 Mb | 2 Gb |
| Ubuntu | 128 Mb | 0,5 Gb |
| CentOS | 1024 Mb | 10 Gb |
Согласно проведенным тестам (несколько примеров результатов тестирований можно посмотреть здесь и здесь) из коробки Debian и Ubuntu несколько опережают CentOS по скорости работы веб-сервера, в тестировании работы баз данных все очень зависит от используемого сервера баз данных и его версии.
- Интеграция с другими системами
Здесь все достаточно логично. Для того чтобы осуществлять интеграцию необходимо иметь тесные контакты между разработчиками интегрируемых систем. Конечно же, проще наладить контакт, с группой официальных представителей, чем с сообществом. Это умозаключение подтверждается практикой: CentOS (как аналог RedHat) одним из первых начал поддерживаться в системах виртуализации Microsoft.
Также именно CentOS лучше других интегрируется с ActiveDirectory. Однако если у Вас уже есть несколько серверов Debian, то не во всех случаях будет рационально разворачивать CentOS, даже если требуется некоторая интеграция. Возможно, в долгосрочной перспективе трудозатраты на интеграцию будут меньше, чем трудозатраты на обслуживание операционной системы, отличной от всех остальных.
В целом подводя итог всему вышеописанному и стараясь ответить на вопрос, заданный в самом начале статьи, можно сказать, что выбирать образ Linux нужно согласно Вашим задачам.
Только предварительно оценив и взвесив все требования к аппаратной платформе, программному обеспечению, окружающей инфраструктуре и администраторским навыкам можно сделать правильный выбор. Однозначно правильного решения нет, и всегда будут какие-то недостатки.
Но, по твердой убежденности автора, эти недостатки можно устранить с помощью дополнительных настроек или решений. А если трудозатраты на исправление недостатков превышают целесообразность — просто пренебречь ими. Ведь у Вас уже есть достаточно аргументов для выбора именно Вашего решения.
Источник: https://system-admins.ru/otlichiya-linux-sravnenie-debian-ubuntu-centos/
Загрузка...
