Для оптимизации производительности и резервного копирования ВМ я использую отдельные диски для временных данных, таких как:
- swap
- логи
- системные temp-папки
- временные БД (например, tmpdb в MSSQL)
- локальные резервные копии, программные пакеты и много другой некритичной информации.
Отдельные диски позволяют сделать 4 важные вещи:
1. Эффективные настройки дискового кэша - "unsafe" отлично подходит для таких данных.
2. Небезопасную оптимизацию типа или места хранения хоста (например, ext4 с отключенным журналированием; разделы, вынесенные из RAID).
* Кстати, я собирался использовать RAW вместо QCOW2, но пока это невозможно, если необходимы VM-снимки (даже если они мне не нужны для этих дисков).
3. Небезопасную оптимизацию настроек или типа ФС гостя (например, exFAT без журналирования вместо NTFS в некоторых случаях).
4. Гораздо более быстрые резервные копии и меньше используемого места за счёт исключения таких дисков из резервного копирования.
Это делает ВМ быстрее, экономя ресурсы хоста и PBS (сюрприз не увидеть чего-то подобного в стандартных рекомендациях по производительности).
Однако, есть 2 проблемы при восстановлении таких ВМ без дисков для резервного копирования:
1. Диски удаляются из VM-конфига. Это делает процесс восстановления дольше и требует ручного вмешательства.
2. Очень гениальная функция "Live restore" вообще нельзя использовать, когда такой диск может быть пустым, но необходим для существования. Потому что если я вручную добавляю диски в конфиг во время восстановления, оно просто проваливается.
Есть ли какие-нибудь решения или, возможно, уже предложенные функции для отслеживания этого?
Я думаю, это может быть что-то вроде:
1. "Unreferenced disk" в качестве необязательного шаблона для замены отсутствующего диска.
2. Переопределение конфига или, по крайней мере, флаг "сохранить оригинал" перед процессом восстановления.
3. Создать и подготовить диск -> одна резервная копия -> затем исключить из резервного копирования + опция восстановления, чтобы использовать "диск-образ из более старой резервной копии, если он отсутствует в текущей".
4. "Из коробки" отдельный тип устройства (как для EFI-дисков) с 1 разделом, списком предопределённых ФС и опциями "никогда не хранить" / "хранить локально".
- swap
- логи
- системные temp-папки
- временные БД (например, tmpdb в MSSQL)
- локальные резервные копии, программные пакеты и много другой некритичной информации.
Отдельные диски позволяют сделать 4 важные вещи:
1. Эффективные настройки дискового кэша - "unsafe" отлично подходит для таких данных.
2. Небезопасную оптимизацию типа или места хранения хоста (например, ext4 с отключенным журналированием; разделы, вынесенные из RAID).
* Кстати, я собирался использовать RAW вместо QCOW2, но пока это невозможно, если необходимы VM-снимки (даже если они мне не нужны для этих дисков).
3. Небезопасную оптимизацию настроек или типа ФС гостя (например, exFAT без журналирования вместо NTFS в некоторых случаях).
4. Гораздо более быстрые резервные копии и меньше используемого места за счёт исключения таких дисков из резервного копирования.
Это делает ВМ быстрее, экономя ресурсы хоста и PBS (сюрприз не увидеть чего-то подобного в стандартных рекомендациях по производительности).
Однако, есть 2 проблемы при восстановлении таких ВМ без дисков для резервного копирования:
1. Диски удаляются из VM-конфига. Это делает процесс восстановления дольше и требует ручного вмешательства.
2. Очень гениальная функция "Live restore" вообще нельзя использовать, когда такой диск может быть пустым, но необходим для существования. Потому что если я вручную добавляю диски в конфиг во время восстановления, оно просто проваливается.
Есть ли какие-нибудь решения или, возможно, уже предложенные функции для отслеживания этого?
Я думаю, это может быть что-то вроде:
1. "Unreferenced disk" в качестве необязательного шаблона для замены отсутствующего диска.
2. Переопределение конфига или, по крайней мере, флаг "сохранить оригинал" перед процессом восстановления.
3. Создать и подготовить диск -> одна резервная копия -> затем исключить из резервного копирования + опция восстановления, чтобы использовать "диск-образ из более старой резервной копии, если он отсутствует в текущей".
4. "Из коробки" отдельный тип устройства (как для EFI-дисков) с 1 разделом, списком предопределённых ФС и опциями "никогда не хранить" / "хранить локально".
