Почему файл.img намного больше реального диска?
xterm-256colorкажется, теперь работает правильно (полные цвета и отсутствие проблем с прорисовкой фона )и имеет функцию BCE (стирания заднего цвета ). Вы можете включить его в tmux, поместив его в свой~/.tmux.conf:
set -g default-terminal "xterm-256color"
Ой типично -только что нашел это:
https://askubuntu.com/questions/537012/dd-image-size-does-it-equal-the-size-of-the-partition
Я предполагаю, что это означает, что этот файл.img на самом деле будет иметь размер самого диска, а не размер используемого в настоящее время пространства
Использование ddбез параметров крайне неэффективно -при каждом чтении будут использоваться блоки по 512 байт. Вы можете настроить ddразмер блока (bs=32M, например ), но есть несколько более простых и более быстрых альтернатив
# Compressed image
ssh root@109.74.201.x "gzip --rsyncable </dev/sda" >/backup/server-images/west.img.gz
# Uncompressed image
ssh root@109.74.201.x "gzip --rsyncable </dev/sda" | zcat >/backup/server-images/west.img
# Uncompressed image with seriously fast network
ssh root@109.74.201.x "cat /dev/sda" >/backup/server-images/west.img
Обратите внимание, что ни один из них не использует dd. Опустите флаг --rsyncable, если ваш gzipне понимает его, или если вы можете абсолютно гарантировать, что никогда не захотите использовать rsyncдля передачи сжатых изображений в будущем.
Между прочим, если какая-либо файловая система на /dev/sdaсмонтирована или какой-либо раздел используется иным образом, ваша резервная копия, вероятно, будет повреждена. Это не то, как выполнить резервное копирование на основе блока -работающей системы.