Предполагая, что каждая резервная копия представляет собой один файл (путем архивирования обоих файлов, указанных выше ), SCP будет более эффективным, чем rsync , поскольку выполняет меньшую общую работу. кроме передачи файла.
Что касается автоматизации, вам нужно настроить так, чтобы либо:
Предпочтительным методом для любого из них обычно являются незашифрованные ключи SSH. После этого вы можете настроить задание cron (на пятом VPS в случае 1 или на каждом из 4 других в случае 2 ), которое будет передавать последнюю резервную копию в нужное место.
Вот быстрый и грязный сценарий оболочки для второго варианта, который скопирует самый последний файл из каталога в удаленную систему:
#!/bin/bash
file=`ls -t "${1}" | head -n 1`
scp -pCB "${1}"/"${file}" ${2}
Запуск с указанием пути к каталогу, в котором хранятся резервные копии, в качестве первого аргумента и строки user@host:/path
, указывающей на местоположение на пятом VPS, в качестве второго аргумента скопирует самую последнюю резервную копию из локальной системы в пятый VPS.
Параметр -p
для SCP сохраняет mtime (, так что вы по-прежнему можете использовать ту же команду find
для прореживания старых резервных копий ), -C
включает сжатие (это может улучшиться, а может и нет производительность, и -B
не позволяет ему запрашивать что-либо.
Нет, GRUB вообще не поддерживает NFS.
Несмотря на то, что строка linux
содержит параметры монтирования NFS, GRUB не будет действовать на них; он просто передает параметры ядру Linux, когда ядро действительно загружается. Как только ядро запустится и начнет выполнять initramfs, оно будет использовать эти параметры для настройки смонтированной корневой файловой системы NFS -.
GRUB загружает initrd.img
, используя точно такой же механизм, как и для загрузки файла ядра. В вашем «простом решении tftp/pxe» механизмом, скорее всего, будет TFTP. (Новейшие версии UEFI также могут поддерживать HTTP, но я пока не уверен, что GRUB может использовать функции HTTP UEFI.)
Как только GRUB загрузит ядро, initramfs и строку параметров загрузки в ОЗУ PXE-клиента,он передает управление системой ядру :GRUB не будет участвовать в каких-либо действиях после этого момента.
Для обработки как устаревшей, так и UEFI-загрузки PXE ваш DHCP-сервер должен считать параметр архитектуры PXE, использовать его, чтобы определить, является ли PXE-клиент устаревшим или UEFI, а затем передать соответствующий путь к загрузочному файлу либо устаревшему PXE-клиенту. загрузчик (например образ GRUB PXE, созданный с помощьюgrub-mkimage --format=i386-pc-pxe
)или загрузчика UEFI (, например. изображение grub.efi
, созданное с помощью grub-mkimage --format=x86_64-efi
).
Для загрузки Clonezilla Live через PXE параметры nfsroot не нужны. Вместо этого ваша строка linux
может выглядеть примерно так:
linux /programs/clonezilla/live/vmlinuz boot=live username=user union=overlay config components quiet noswap edd=on nomodeset nodmraid locales=en_US.UTF-8 keyboard-layouts=us ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch=no net.ifnames=0 nosplash noprompt fetch=http://URI_path_on_your_server_containing/filesystem.squashfs
Очевидно, замените часть http://URI_path_on_your_server_containing/filesystem.squashfs
фактическим URL-адресом, указывающим на HTTP-сервер, с которого Clonezilla initramfs сможет загрузить файл Clonezilla filesystem.squashfs
. Если вы предпочитаете клавиатуру, отличную от -США, вы также можете изменить партию keyboard-layouts=us
. Эта строка опций изначально была написана в соответствии с инструкциями:
и ссылка на параметры загрузки Clonezilla в:
Я использовал его с SYSLINUX при устаревшей загрузке PXE и загрузчике iPXE.org в UEFI, и когда я тестировал его с clonezilla -live -20191024 -eoan -amd64.zip, он работал.