27.07.2022 16:00
Bright_Translate 23 4500 Источник

GNU-версию утилиты архивирования tar, равно как и её старые версии, можно использовать через сетевое подключение по протоколу ssh. От telnet/nc стоит отказаться, так как они не гарантируют безопасность соединения. Создавать архивы можно с помощью каналов (pipe) Unix/Linux, и ниже я продемонстрирую ряд примеров использования tar по ssh для архивирования в Linux, BSD/macOS или Unix-подобных системах.

Синтаксис использования tar по SSH


Установка соединения с хостом box по ssh и выполнение tar:

$ ssh user@box tar czf - /dir1/ > /destination/file.tar.gz

либо:

$ ssh user@box 'cd /dir1/ && tar -cf - file | gzip -9' >file.tar.gz

Следующая команда приведёт к созданию резервной копии каталога /wwwdata на хосте dumpserver.nixcraft.in (IP 192.168.1.201) по ssh:

$ tar zcvf - /wwwdata | ssh user@dumpserver.nixcraft.in "cat > /backup/wwwdata.tar.gz"

либо:

$ tar zcvf - /wwwdata | ssh vivek@192.168.1.201 "cat > /backup/wwwdata.tar.gz"

Образец вывода:

tar: Removing leading `/' from member names
/wwwdata/
/wwwdata/n/nixcraft.in/
/wwwdata/c/cyberciti.biz/
....
..
...
Password:

В следующем примере архивируем /data2/, попутно используя gpg:

$ tar zcf - /data2/ | gpg -e | ssh vivek@nas03 'cat - > data2-dd-mm-yyyy.tar.gz.gpg'

Обратите внимание, что при использовании sudo или любой другой команды, требующей аллокации псевдо-терминала, здесь может возникнуть ошибка:

sudo: sorry, you must have a tty to run sudo

Для её избежания нужно сопроводить команду ssh флагом -t:

$ tar zcvf - /wwwdata | ssh -t vivek@192.168.1.201 "sudo cat > /backup/wwwdata.tar.gz"


Копирование с удалённой машины (server1.cyberciti.biz) в локальную систему выполняется так:

$ cd /path/local/dir/
$ ssh vivek@server1.cyberciti.biz 'tar zcf - /some/dir' | tar zxf -

▍ Резервное копирование/зеркалирование жёсткого диска под Linux


Команда для копирования всего HDD /dev/sdvf с локальной машины на облачный бэкап-сервер AWS EC2:

$ dd if=/dev/sdvf | ssh backupimg@vpc-aws-mumbai-backup-001 'dd of=prod-disk-hostname-sdvf-dd-mm-yyyy.img'

Для восстановления локального диска из образа с сервера эту команду нужно реверсировать. Если продолжить пример выше, то выглядеть это будет так:

$ ssh backupimg@vpc-aws-mumbai-backup-001 'dd if=prod-disk-hostname-sdvf-dd-mm-yyyy.img' | dd of=/dev/sdvf

▍ Перенос данных в новую систему Linux


Проблема с scp и другими командами, копирующими структуру каталогов, в том, что символические ссылки, специальные файлы устройств, сокеты, именованные каналы и прочие компоненты не копируются. Поэтому мы используем tar по ssh. Скопируем, к примеру, все данные из nuc-box.

Открываю терминал и выполняю команду ssh вместе с tar:

$ ssh vivek@nuc-box 'tar czf - /home/vivek' | tar xvzf - -C /home/vivek

▍ Применение tar по SSH к ленточному накопителю


В Linux по умолчанию первым ленточным накопителем SCSI является /dev/st0. Подробнее о соглашении именования таких накопителей в Linux можете почитать здесь (англ.). Для большей ясности можно использовать команду dd:

$ tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"

Также есть вариант отправить бэкап на удалённое ленточное устройство:

$ tar cvzf - /wwwdata | ssh root@192.168.1.201 "cat > /dev/nst0"

С помощью команды mt можно перемотать плёнку, после чего сделать с неё дамп командой cat:

$ tar cvzf - /wwwdata | ssh root@192.168.1.201 $(mt -f /dev/nst0 rewind; cat > /dev/nst0)$

▍ Извлечение tar по SSH


Синтаксис для этой операции весьма прост:

$ cat my-data.tar.gz | ssh user@server1.cyberciti.biz "tar zxvf -"
$ cat my-data.tar.gz | ssh user@server1.cyberciti.biz "cd /path/to/dest/; tar zxvf -"

В данном примере выполняется восстановление бэкапа с удалённой машины в локальный каталог по ssh:

$ cd /
$ ssh root@192.168.1.201 "cat /backup/wwwdata.tar.gz" | tar zxvf -

Если вы решите задействовать эту команду в задачах cron или скриптах, подумайте об использовании ключей ssh, чтобы исключить пароли.

▍ Создание архива с индикатором прогресса


По умолчанию утилита pv в вашей системе может отсутствовать. Если это так, то для её установки используйте команду apk в Alpine Linux, dnf/yum в RHEL & co, apt/apt-get в Debian и Ubuntu & co, zypper в SUSE/OpenSUSE, pacman в Arch Linux.

Команда pv позволяет наблюдать прогресс прохождения данных по каналу. Вот её синтаксис:

$ cd /dir/to/backup/
$ tar zcf - . | pv | ssh vivek@server1.cyberciti.biz "cat > /backups/box42/backup-dd-mm-yyyy.tgz"
$ cd /tmp/data/
$ tar zcf - . | \
pv | \
ssh vivek@centos7 "cat > /tmp/data.tgz"


▍ Дополнительные примеры использования tar по SSH


$ tar cvjf - * | ssh vivek@nixcraft "(cd /dest/; tar xjf -)"
$ tar cvzf - mydir/ | ssh vivek@backupbox "cat > /backups/myfile.tgz"
$ tar cvzf - /var/www/html | ssh vivek@server1.cyberciti.biz "dd of=/backups/www.tar.gz"
$ ssh vivek@box2 "cat /backups/www.tar.gz" | tar xvzf -
$ tar cvjf - * | ssh root@home.nas02 "(cd /dest/; tar xjf - )"

Больше подробностей об использовании команд tar/ssh/bash можно узнать с помощью help или man:

$ man tar
$ man bash
$ man ssh

▍Примечание об SSHFS


С помощью sshfs можно монтировать удалённые каталоги и выполнять tar:

$ mkdir /data/
$ sshfs vivek@server1.cyberciti.biz:/ /data/
$ tar -zcvf /data/file.tar.gz /home/vivek/

▍ Заключение


В этой небольшой статье мы вкратце познакомились с возможностями использования tar в сеансах ssh для безопасной передачи архивов, файлов и образов. В некоторых случаях для ускорения передачи можно избежать сжатия на обеих сторонах. Например, так:

$ tar cvf - /wwwdata | ssh user@dumpserver.nixcraft.in "cat > /backup/wwwdata.tar"
$ ssh vivek@server1 'tar c .' | tar xvf - -C /home/vivek/


Комментарии (23)


  1. pv2pv
    27.07.2022 16:35
    #24570086
    +8

    Хорошая статья о том, как в UNIX с помощью < , | и > сделать всё


    1. dlinyj
      27.07.2022 16:47
      #24570158
      +1

      Основа *nix — это файлы и каналы.


    1. sHaggY_caT
      27.07.2022 16:58
      #24570206

      Хорошая

      Простите за снобизм, но это не так. Хабр будто бы вырождается в Пикабу, рассказывая о таких вещах, которые, в общем-то, должны знать все


      1. Bright_Translate Автор
        27.07.2022 17:10
        #24570264
        +3

        То есть вы считаете, что на Хабре нет места неопытным в системном администрировании читателям (и, видимо, во многих других IT-областях тоже), которые только осваивают эту науку, либо просто узнают какие-то заинтересовавшие их внезапно нюансы?


        1. sHaggY_caT
          27.07.2022 17:23
          #24570312
          -2

          Нет, я считаю, что первый скилл джуниора, который он должен уже иметь, это способность заглянуть в гугл/стековерфлоу с запросами вроде такого:

          site:habr.com tar+ssh


          1. Bright_Translate Автор
            27.07.2022 17:47
            #24570432
            +4

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


            1. edo1h
              28.07.2022 00:25
              #24571418
              +2

              если я правильно понял, речь не про то, что статьи о tar не нужны, а о том, что такие статьи уже есть (в том числе, сюрприз, и на хабре)


        1. Johan_Palych
          28.07.2022 06:05
          #24571740
          +4

          Неопытным в системном администрировании
          надо читать официальную документацию.
          Резервное копирование системы:

          https://help.ubuntu.ru/wiki/backup
https://wiki.archlinux.org/title/Synchronization_and_backup_programs_(Русский)
https://wiki.archlinux.org/title/Dd_(Русский)
https://wiki.archlinux.org/title/Full_system_backup_with_tar


        1. simpleadmin
          28.07.2022 09:08
          #24572070
          +2

          Может просто не надо засирать хабр бестолковыми переводами, учитывая, что на хабре есть намного более полезные статьи на эту тему.
          Всё описанное в переводе отлично ужимается в один абзац "Удалённое исполнение кода"


      1. iig
        27.07.2022 17:51
        #24570452
        +5

        должны знать все

        Вы лично про магию < | > откуда узали? Возможно, кто-то узнает из habr.com и перейдет на светлую сторону ;)


        1. mvv-rus
          27.07.2022 23:05
          #24571296
          -1

          Не помню откуда узнал. Но на VM/SP CMS мне в 80-х такой магии для скриптов на REXX не хватало. Наверное, в какой-то книге про Unix вычитал, так что про то, что COMMAND.COM в DOS в нее умел, я был как-то изначально в курсе.


          1. iig
            28.07.2022 09:20
            #24572132
            +3

            я был как-то изначально в курсе

            Не у всех это заложено в прошивку.


            1. mvv-rus
              29.07.2022 19:20
              #24579120

              Ну, вы спросили — я ответил. Зачем много минусов-то?

              Если про прошивку (закладываему в институте ;-) ) то у меня в нее был заложен Фортран для ЕС ЭВМ (а еще — Алгол для БЭСМ-6).
              А остальное пришлось, таки да, изучать после института, многое — попутно. Что касается перенаправления потоков ввода и ввода (< и >)- это какая-то очень старая идея, по крайней мере в Фортране ЕС ЭВМ она уже была с каких-то незапамятных (для меня времен): были стандартные номера (5 и 6 ЕМНИП) которые назначались на конкретные наборы данных в JCL. А вот каналов (| AKA pipe) — таки да, не было, это была идея из Unix (AFAIK оригинальная). Но в СССР Unix было мало, потому как основные производители копировали совсем другие, глубоко проприетарные, системы. Так что с Unix я в советское время не работал. Но книжки разные читал, в какой-то из них и про каналы прочел, и идея мне понравилась — как раз, потому что требовалась, а не было.
              А в COMMAND.COM полноценных каналов — соединияющих две работающие одновременно прграммы — не было: DOS, как все, наверное, знают была системой однозадачной, поэтому программы запускались по очереди, а каналы между ними в COMMAND.COM эмулировались через временные файлы.
              А Windows (оригинальной, 3.х) вообще не было своего shell и, соответственно, каналов — видимо поэтому программисты на Windows, для кого она была первой системой, каналы часто не знают и не любят. Но я не из их числа.


      1. FanatPHP
        28.07.2022 07:50
        #24571852

        Не стреляйте в пианиста, он играет, как умеет. У переводчика план по валу.


        Хоть я и согласен с вами по сути, но надо ж понимать бизнес-модель Хабра. Его владельцы хотят кушать, а кроме как с компаний денег взять особо не с кого. Компании тоже хотят кушать, и чтобы о них на забывали, каждый день на канале должно появляться новое чтиво для гиков, чтобы повтыкать за утренним кофе.


        Учитывая, же какой треш тут гонят новостнюки, то лучше пусть будет хоть это. Не самая плохая статья для перевода.


      1. Tim777
        28.07.2022 14:09
        #24573732
        +2

        Какие все великие ;) Есть много о чем не заглядываешь в man, так как давно его отштудировал и тут вдруг на форуме рассказывают про ключик -bv у sendmail.


  1. mvv-rus
    27.07.2022 22:59
    #24571282
    +3

    Спасибо, напомнили прежние времена. Более 20 лет назад я как раз примерно так, с помощью tar+ssh+dd бэкапил файловый сервер под Netware 3.11 на стриммер, подключенный к Linux (потому что стример был ровно один и, вообще-то, был закуплен под интернет-проект): tar и клиент ssh были собраны под Cygwin и выполнялись заданием на NT, tar через стандартый редиректор (если кто не в курсе, так в NT официально называется клиент для файл-сервера) для Netware читал файлы и загонял их в архив, а поток данных архива шел на вход ssh, запускавшего dd на Linux-машине, которая писала этот поток на ленту. Короче, зоопарк был полнейший, но как ни странно, все работало. И даже один раз пришлось с этого бэкапа восстанавливаться (неожиданно — сравнительно успешно: в бэкап всего лишь небольшая часть файлов не попала, потому что директорию с ними забыли).


  1. FanatPHP
    28.07.2022 08:02
    #24571884
    +3

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


    И замечание для переводчика. Как можно видеть, символ приглашения у автора гуляет между $ и #. При этом для оригинала это не критично — там подсветка работает нормально, а вот на хабре вся строчка превращается в комментарий. Рекомендую все приглашения в примерах сделать виде $


    1. Bright_Translate Автор
      28.07.2022 08:04
      #24571892

      Спасибо, исправлю


    1. iig
      28.07.2022 09:26
      #24572160
      +2

      рекомендация отключать сжатие для ускорения передачи файла по сети вызывает лёгкое недоумение

      20 лет назад это было актуально, когда процессоров с AES не было. Да и сейчас тоже, очень легко включить сжатие уже сжатых файлов внутри сжатого архива.


    1. edo1h
      29.07.2022 06:06
      #24576336
      +1

      Ну и рекомендация отключать сжатие для ускорения передачи файла по сети вызывает лёгкое недоумение

      использование дефолтного сжатия (однопоточный gzip) на гигабитном канале обычно приводит к существенному снижению скорости копирования.
      lz4 или ztsd тут куда более уместны (последний умеет даже адаптивную степень сжатия)


  1. dtmse
    28.07.2022 11:45
    #24572930
    +1

    Это все конечно хорошо. Но подскажите, как сделать так, чтобы, к примеру, скорость резервного копирования быстрого raid-массива по сети 10 Гбит/с не утыкалась в производительность шифрования ssh.


    1. saboteur_kiev
      29.07.2022 04:18
      #24576256
      +1

      nfs


    1. edo1h
      29.07.2022 06:23
      #24576348

      не уверен, что во всех версиях/конфигах openssh так, но сейчас проверил, у меня по умолчанию выбирается chacha20-poly1305, который, конечно, быстрый, но ускоренный аппаратно aes всё-таки быстрее.
      попробуйте ssh -c aes128-gcm@openssh.com, на моих серверах гигабайт в секунду получается, как раз под 10G сеть )