Как сделать бекап системного окружения на сервере, перед тем как ставить php, mysql и прочее?

Чаще беру ВДС на Ubuntu и там все ставлю

В любом нормальном облаке можно сделать снапшот системы.

Т.е. надо бекапить окружение а не файлы и БДы сайтов на сервере.

Не надо изобретать велосипеды на костылях.

Со всем файлом сайтов на террабайты?

Докер? И тогда кроме ssh ключа и установки докер демона ничего не нужно. Остальное - docker-compose. Легко обновлять, легко повторить окружение

раздели носитель на несколько разделов. или пропиши в конфиге впс несколько разделов.

вариант впрямую: рсинкать бинари корня к себе и обратно.

Не использую Докер на продакшене. Не спрашивайте почему. Надо как-то по другому. В любом случае большинство людей, к чьим сайтам доступ я имею держат их на серверах с Убунту и Докер не потерпят. А ПХП бывает обновить надо.

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

К себе бекапы заливать никакого делания нет. Хотелось бы видеть бекапы окружения в виде архивов на сервере

ага, разделяй и властвуй :)
разные по структуре/важности файлы должны лежать на разных разделах.
доиграешься еще и до /var/log на отдельном разделе с sync ^)

Как вариант файлового бекапа корня в образ на сервере - каменный топор tar squashfs образ.

не потерпят

Большинству абсолютно пофиг как работает, пока оно работает.

Вообще-то это стандартная практика. Как раз за данные и ОС на одном диске по рукам бьют.

файлом сайтов на террабайты

Что за сайты такие? БД как бы вообще должна быть в отдельной VM.

Честно говоря реально никогда не встречал, чтоб на ВДС-е кто-то делал разделы на накопителе и их по отдельносмти бекапил. Может не знакомился пока с таковыми людьми. Или они благоразумно мне доступы не давали.

Давайте подойдем с другого конца. Сайты хранятся в /var/www Если сделать архив всех остальных файлов на сервере, кроме этой директории, и если что-то подйдет не так, восстановится с этого архива - оно ж работать будет? Насколько это правильный подход?

бекапы окружения в виде архивов на сервере

Бинго!

оно ж работать будет?

Будет конечно. Только непонятно, зачем тебе все эти телодвижения?

Насколько это правильный подход?

Максимально наивный подход. Я не знаю с какой Луны ты свалился, но так вообще никто не делает. Разве что васяны, которые первый раз у слышали про сайты и пошли пилить себе vps. Делается VM туда ставится базовая система. Подключается отдельный диск и туда ставятся «сайты». БД крутится отдельно, на отдельной VM. Т.о. ты можешь делать снапшоты отдельно БД, кода и собственно ОС. Если что-то сломалось, то ты просто разворачиваешь новую VM из снапшота, подключаешь туда диск с данными и поехали. А с архивами на гигабайты ты будешь неделю пердолиться распаковывать.

VM - это Virtual Machine? Мне 3 виртуальных сервера на хостинге покупать? Под систему, сайты и базы данных? Или можно на одном ВДС-е разбить?

А разбить накопитель ВДС-а на разделы по SSH какой командой можно? Я ж не буду партишн меджик на сервер ставить 🤣.

Можно ссылку на док или даже на правильную формулировку вопроса.

Какой в том глубинный смысл? Установка жопача и пхп/мойсекель ничего в принципе сломать не может. Я на сервере все что относится к приложениям в /srv кладу и ее/его бекаплю

А на будущее советую Btrfs/ZFS использовать в качестве файловой системы. Там есть снапшоты и средства для управления ими.

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

zfs вроде как достаточно ресурсоемкая штука и ее эксплуатация на вдс с 2 ядрами и 2Гб памяти может быть расточительным

❯ cat /proc/loadavg 
0.42 0.32 0.27 1/1187 39796

Два раздела на разных дисках с шифрованием через LUKS + Btrfs RAID-1 на них с ZSTD. 0.5-3% на каждое ядро на Ryzen 5600G. Не думаю что дополнительная нагрузка даже 5% на ядро в случае с Btrfs будет критична на двухядерном дерьме. Говносайт на вротпрессе от силы на процентов 30 грузить будет…

У меня на серваке с уптаймом 120 дней нагрузка около 0.9. Там тоже Btrfs. И он слабее домашнего пека, хотя тот же gitlab уж очень грузит систему

ZFS раму жрет только при включенной дедупликации. Я в оправдание выступаю, хотя мне эта ZFS не нравится, ее нет в ядре, и она даже /etc/fstab не использует (я знаю что «legacy» включить можно, но это неправильно)

Надо как-то по другому

containerd?

Не надо так делать. Сам процесс распаковки архива в корень довольно нетривиален, забодаешься настраивать игнор определённых файлов, не поместишься по размеру, затрёшь что не надо, забудешь удалить то чего не было на момент паковки архива. В конце концов, сам архив в процессе перезаписи корня может пострадать, ещё и лишнее что-то можно запороть, включая живые базы данных. И это ещё не говоря о том как поведёт себя сервер со всеми запущенными процессами и модулями ядра, если вдруг всё подменить. Абсолютно прекрасный способ прострелить себе оба колена одним выстрелом. Такое если и делают, то гасят машину, монтируют корневой раздел в какую-то другую виртуалку, и аккуратно что-то фиксят.

Второй вопрос: а собственно нафига? Что ты такое не сможешь за час восстановить из общедоступных данных? Раскатываешь новую виртуалку, apt update, apt upgrade, reboot, готово. Спасай пользовательские данные, а ОС пускай в расход. Ну и само собой держи копию твоих исходников у себя.

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

Четвёртое: учи докер. Его не просто так нахлебавшись смуззи придумали. Это как раз для управления версиями, всякими особенными инсталляциями базы и пыха. Откатить на предыдущую/любую другую версию проще простого, причём сразу со всеми зависимостями и особенностями вплоть до версии libc. Если версия работает у тебя локально, то в 99% случаев будет как часы работать и в продакшене.

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

https://help.ubuntu.com/community/BackupYourSystem/TAR

Тут есть ряд непонятных моментов. У меня сложилось впечатление, что оп нанимается вносить изменения в уже существующую у клиента систему. Т.е. он не с нуля ее разворачивает. Поэтому он ищет а-ля виндовый денвер. Чтобы папочку с бинарниками и конфигами забэкапил, а в случае необходимости назад подсунул и всё в первозданном виде. Поэтому советовать lvm-снапшоты, btrfs, zfs + специальную разметку разделов(чтобы в снапшот не включались логи, файлы хранилища бд, файлы загруженные клиентами в тот же вордпресс или Битрикс) как будто бессмысленно

Как сделать точку возрата (бекап) перед тем как ставить или обновлять …

Если места размещения VPS/VDS-ок меняются, то так вообще не надо делать. Изучите в достаточной степени какой-нибудь Ansible, или просто Bash+SSH, и нацарапайте собственные скрипты подготовки базовой системы (установка соответствующих пакетов и конфигурационных файлов), ну и отдельно - Nginx, PHP и пр. Такие скрипты будете просто запускать со своего локального компа на «нулевую» Ubuntu.

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

разбить накопитель ВДС-а на разделы по SSH

А ты точно настоящий сварщик? Ничего разбивать не надо. Надо disk provisioning.

Можно ссылку на док

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

«Обычно имеются средства формирования снапшотов» - да, все это есть. Пользовался. Работает. Надо как-то по-другому.

«Т.е. он не с нуля ее разворачивает. Поэтому он ищет а-ля виндовый денвер» Сейчас разворачиваю с нуля на Убунту. А-ля Виндовый денвер уже нашел. Докер называется. Но он у меня для разработки в рамках моего ПК, а не переноса контейнеров на сервер.

«Обновление любого из них может привести сайт в нерабочее состояние.» спасибо, что понимаете.

Ок, пытаюсь разбить накопитель сервера на разделы.

Смотрю какие диски доступны (вроде 1):

fdisk -l
Disk /dev/vda: 250 GiB, 268435456000 bytes, 524288000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3b3f2586

Device     Boot Start       End   Sectors  Size Id Type
/dev/vda1        2048 524287999 524285952  250G 83 Linux

Захожу в диск на котором хочу создать раздел. Пишет, что плохая идея.

fdisk /dev/vda
This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.

Но я, настаиваю… Ввожу n - add a new partition

Command (m for help): n
All space for primary partitions is in use.

Не дает. ☹️ Что делать?

От дисков место откуси и сделай два раздел, а далее Btrfs в RAID-1 на них, /srv монтируй на этот RAID и делай снапшоты.

А как сделать 2 раздела? Я думал fdisk и n.

Сначала нужно изменить размер файловой системы ext4, потом изменить размер раздела через cfdisk, например, и с помощью его же создать новый

ок, уменьшаю раздел до 10 Гигов:

resize2fs /dev/vda1 10G
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
resize2fs: On-line shrinking not supported

Что ему не нравиться?

Может, я чего не понимаю, но разве бэкапа /etc тебе не достаточно?

Честно - я не знаю. Если считаешь, что nginx, php, mysql, composer, certbot ставтся в /etc и работают из него, то вариант бекапить папку /etc меня устраивает.

Но так ли это - я не знаю…

Они туда не ставятся, но там хранятся их конфиги.

Тогда нужно грузаться в Rescue режим и там вс размеры изменить. И 10 гигов для корня мало. Надо 20-30 минимум

всю эту хрень надо в докере держать. так переезжать проще, но его могут забанить для рф

можно вообще не заморачиваться. все конфиги - мусор. главное данные базы (папочка с файликами) ее бекапить, а конфиги можно в том же гитхабе хранить в приватном репозитории как и все скрипты. данные же базы, загруженные картинки и тп в конфигах или симлинками в /srv куда-нить ложить, а потом бекапить (скрипты тоже там можно держать). конфиги храним в гите (весь /etc или отдельные его каталоги), скрипты и их данные в /srv

… да, все это есть. Пользовался. Работает. Надо как-то по-другому.

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

«вместо того, чтобы приобрести необходимые базовые знания по части развертывания PHP-приложений» - вот приобретаю. У меня такой подход самообразования методом деструктивного воздействия на тестовый продукт.

Хорошо. Давайте представим, что в etc действительно находится все для работы php и других компонентов окружения.

На чистом сервере создаю архив с etc. Ввожу «php» - пишет такого нет, но можно установить. Устанавливаю - работает.

Потом удаляю etc и восстанавливаю с архива. Опять ввожу «php», но теперь не пишет, что такое можно установить, а пишет

-bash: /usr/bin/php: No such file or directory

Значит бекапа одной лишь etc недостаточно для получения точки восстановления системного окружения?

… У меня такой подход самообразования методом деструктивного воздействия на тестовый продукт.

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

… Потом удаляю etc и восстанавливаю с архива. Опять ввожу «php» …

Вот это и называется - отсутствие начальных знаний)

… вы удаляете сами не знаете что - потом восстанавливаете сами не знаете что) Заглянуть внутрь пробовали? Понять что там и для чего? Совершать надо осмысленные действия, а не то, что вам кто-то здесь брякнул. Здесь на форуме тусуются люди с весьма разной степенью компетентности.

для таких издевательств давно придумали виртуалки - там монжо намудрить что угодно.

всю эту хрень надо в докере держать. так переезжать проще, но его могут забанить для рф

так локальное зеркало с нужными образами поднимите

Сейчас модно делать Infrastructure as a Code: все настройки делаются через ansible/puppet/salt, код доторых находится под контролем git. Можно откатиться на любой git-commit или сделать новую VM, с полностью идентичными настройками.

P.S. От резервирования данных это не избавляет, конечно.

В принципе, если надо просто тупой бэкап всего, что в системных папках, то могу порекомендовать отличный cli-backup тулз: restic. Я им бэкаплю по расписаню как /home, так и некоторые системные папки. Тулз объективно лучше rsync-а – умеет шифрование + incremental backups одновременно. Пакеты есть под все ОС, по моему. На фряхе, по крайней мере, ставится через pkg, поэтому в линуксах оно точно должно быть.

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

Ты же весь этот софт будешь ставить из пакетов, а не через make install надеюсь? Тогда зачем здесь вообще снапшоты?

Чаще беру ВДС на Ubuntu и там все ставлю. Но часто ошибаюсь.

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

1. Существующий сайт/проект пусть висит на ubuntu/mysql|mariadb/php/nginx текущих версий до упора, потом разово напряжёшься и обновишь (см пункт 2)

2. Перед обновлением тренируйся на кошках (разверни виртуалки с копией прода и вволю их ломай полностью)

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

Ты не с той стороны подходишь к этому вопросу.

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

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

Самый простой способ это написать docker-compose.

Альтернативно можно использовать ansible.