rPman

Xeon L5630

жуть какие тормозные (в singlethread они как типовая машина уровня 2013г ~1000 попугаев, когда как современное железо дает 3000-4000), а еще контроллер nvme у тебя небось китайский нонейм, плюс у тебя виртуализация proxmos дает накладные расходы (минус 30%-90% cpu, именно так) плюс ты же виртуальный контроллер создаешь, он именно на мелких операциях так же даст накладные расходы.

Хочешь реальную скорость, тестируй из нативно запущенной ОС.

Полагаю именно это показывает разницу в скорости IOPS между домашней машины и 'сервером'.

google: (lxc or lxd) (breakout or escape) container, первая же ссылка с описанием и примерами готовых утилит

docker основан на lxd с теми же уязвимостями.

Эти технологии не подходят для запуска злонамеренного кода, только доверенного.
lxc используется для удобной изоляции конфигураций различных версий пакетов из зависимостей приложений. А так же изоляции от выбранной ОС (внутри она как бы своя), например какой-нибудь snap/flatpack пользуются той же основой.

Конечно же нет.

И да VPS уже является гостевой виртуальной машиной, каскадная виртуализация поддерживается только для ограниченного типа комбинаций типов систем виртуализаций. proxmox не даст себя запустить внутри гостевой ос.

upd. пишут что можно с ограничениями функционала, т.е. если внутри vps поставить VirtualBox, и уже внутри него запустить proxmox... то это извращение может даже заработает.

Если в момент создания снапшота ты штатно останавливал 1c (и в идеале всю операционную систему) то снапшот будет консистентным

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

Если используется паравиртуализация (скорее всего если гостевая ос - linux то она будет использоваться), то создание снапшота и его восстановление равнозначно снятие процесса через kill (причем скорее всего каким-нибудь ключом -BUS, так как сервера с критичным отношением к данным слушают обычный kill и доделывают критичные записи перед его исполнением), т.е. файловая система не будет нарушена.

p.s. лучшим и самым оперативным бакапом является настройка master-master репликации базы данных (в твоем случае это pg) на резервную ноду, и при сбоях основной, резервная база будет максимально точной и рабочей базой, если реплицировать и файловую систему (средствами файловой системы или хранилища, так же master-master) на нее же, то ноду можно будет использовать как полноценный сервер, запуск которого - секунды (после чего можно чинить основной сервер, восстанавливать репликацию, при правильной настройке она догонит по изменениям теперь уже резервную базу, и теперь уже эта нода будет резервной к текущей рабочей, так меняя местами ноды можно получить непрерывную работу сервера, устойчивого к сбоям оборудования и сети)

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

самый тупой пример, берешь livecd ubuntu, загружаешься, монтируешь по сети целевой диск, куда сложить файлы (если тебе сразу диск нужен, советую nbd например идет в поставке с qemu, во всех вариациях как сервер так и клиент) и копируешь с помощью dd или partclone (он, зная файловую систему будет пропускать не занятые сектора, что еще быстрее)

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

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

Красиво реализовать не получится.

P.s. резервное копирование на ту же машину это сценарии защиты от пользователя и ошибок в ПО, это лучше и эффективнее разрешать снапшотами, либо файловой системы либо системой виртуализации. Не рекомендую снапшоты lvm, при них кратно деградирует скорость записи.

Зачем? очень важный вопрос, зачем платить ресурсами (память, процессор, накладные расходы дает даже паравиртуализация lxc) да еще и устраивать многоуровневые системы для хранения данных?

Все активно забывают, что доступ к файлам по сети в домашних конфигурациях (это 1гбит) - медленно, больше сотни мегабайт в секунду не получится, плюс заметный оверхед на протоколы (самба дает заметный, особенно это видно когда с мелкими файлами работаешь), плюс нагрузка на процессор NAS (например iscsi выше нагружает чем простой nbd).

Вторая неприятность, большие системы виртуализации типа xen могут вообще не давать удобного (т.е. штатного интерфейса) механизмы работы с локальными образами или с образами nbd (т.е. работать можно но только как ручные настройки, т.е. возвращает в ковыряние в конфигах вместо того чтобы в интерфейсе выбрать что либо).

Как это ни странно, самая удобная система виртуализации для домашнего пользователя (нет кластера и его фишек) - это VirtualBox

Так же штатный libvirt имеет свой интерфейс и он так же рекомендуется как основной инструмент виртуализации (к нему доустанавливаются поддержка lxc а так же сетевых накопителей и становится совсем неплохо), так же для домашнего использования без кластера и его фишек

мало информации

Вангую - диск, куда копируешь файлы - медленный (например флешка или hdd с фрагментацией), пока lazy writes кеш в оперативной памяти не заполнился, скорость лимитирована либо скоростью чтения 'откуда' либо скоростью самой сети (гигабитные сети дают порядка 120мб/с, это реальная скорость, только что проверил на своем дешевом железе), затем скорость падает до максимальной скорости приема файлов на диске, дисковый кеш освобождается фоном в т.ч. после прерывания копирования

У тебя варианты
за кеширование пусть отвечает:
- ZFS, будет доступно только режим на чтение
- bcache - создается блочное устройство, которое в свою очередь уже форматируешь под желаемую фс, будет доступен режим кеширования записи (опасно, при смерти ssd потеряешь данные, я экспериментировал, убил два ssdшника за пару лет в таком режиме, в момент смерти файловая система повреждается, ос подвисает, так как часто ssd-шники в режиме чтения после этого еще работают, данные в основном вытаскиваются, но время на восстановление я тогда потратил), настоятельно рекомендую при использовании кеширования записи bcache, ssd брать два в режиме raid1 mirror

за RAID:
- отдать на откуп управление raid на ZFS, получишь максимальную гибкость (операции ребалансировки не будут затрагивать незанятое данными место)
- отдать RAID на откуп mdadm
- (не вариант, не делай так) организовать RAID на основе аппаратного контроллера в материнской платы, кешированием так же занимается ZFS
если raid контроллер не имеет своей оперативной памяти с аккумулятором для сброса этой памяти на диск в момент потери энергии, то выбирать такой рейд контроллер нет никакого смысла, а вот проблем будет тьма, особенно в текущей ситуации с проблемами с поставками, так как аппаратные рейды привязывают массив к вендору, и при смерти контроллера/материнки у тебя будет проблема с извлечением данных (это реально но долго и сложно)

p.s. можно выбрать btrfs, по функционалу, чуть хуже (нет онлайн дедупликации, но много ли ее включают дома на zfs, ведь это потребует прилично оперативной памяти), нет встроенного ssd кеша но есть онлайн патчи между снапшотами за счет которых можно построить неплохую систему инкрементальных бакапов с максимальной производительностью (можно делать бакапы хоть ежеминутные, лучше объединить с рабочим софтом, чтобы он управлял моментом создания снимка) с отправкой инкрементальных патчей на стороний сервер (где их тут же можно и развернуть для мгновенного переключения на этот сервер при смерти основного)

Как таковой миграции именно с proxmox нет да и не думаю что актуальна такая примитивная операция как пункт меню в интерфейсе.
https://pve.proxmox.com/wiki/Migration_of_servers_...

Внутри виртуалок нет особой необходимости создавать LVM, в 99% ситуаций возможностей снапшотов виртуальной машины хватает за глаза.

По поводу увеличения места, практически все VM поддерживают динамически расширяемые контейнеры, т.е. файл с контейнером будет занимать ровно столько места, сколько реально используется (обратно не уменьшается, только увеличение), соответственно создавайте виртуальную машину с терабайтовым диском, а внутри контролируйте лимитами или заранее созданной маленькой файловой системой, простейший ext3 умеет на лету увеличивать размер, заполняя больше места (только место с конца тома).