Бэкап всего сервера linux

Резервное копирование на Linux — Бэкап Linux сервера | Boodet.online

Пошаговая инструкция созданию бэкапа и восстановлению для ОС Linux. Бэкап всей системы, бэкап сервера и резервное копирование по расписанию.

Бэкап Linux-серверов

Резервное копирование и восстановление в Linux выполняют с помощью специальных команд: tar, cpio ufsdump, dump и restore. Их хватит для бэкапа и восстановления небольших объемов данных. Чтобы сохранить и поднять сервер большой компании, потребуются гибкие готовые решения, например, Symantec NetBackup, EMC NetWorker или Amanda.

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

Что это и зачем нужно?

Чтобы сделать резервную копию сервера на Linux, мы будем использовать командную строку и программу rsync. Есть и более современные программы с красивым и более понятным интерфейсом, но алгоритмы rsync стабильные, надежные, допускают использование кода. А еще она использует минимальное количество трафика (может вычислить разницу между файлами в исходном и целевом каталоге и передавать только различия между двумя версиями файла).

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

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

Создание резервной копии

В этой статье специалисты Boodet.Online расскажут, как создавать резервные копии сервера Linux на внешний диск, удаленный компьютер и по SSH-соединению.

Бэкап на жесткий диск

Если вы не используете облако или протоколы безопасности требуют хранения бэкапов Linux на внешнем диске, скопируйте сервер на жесткий диск: SSD — если хотите, чтобы восстановление было быстрее, или HDD — для большей надежности.

Первый шаг — узнать путь к диску. Откройте браузер файлов (например, Nautilus) в GNOME и найдите имя диска на боковой панели. Наведите указатель мыши на имя внешнего диска — путь будет виден во всплывающей подсказке (например, /media/boodet/NEWHDD).

Теперь скопируйте содержимое из исходного каталога. В командной строке нажмите r — это запустит процесс копирования всех вложенных подкаталогов сервера Linux и их содержимого:

rsync -r / server / boodet / Documents / / media / boodet / NEWHDD /

После завершения процесса вы вернетесь в командную строку. Проверьте, появились ли каталоги на внешнем диске.

Чтобы скопировать данные с сервера Linux в определенный каталог на целевом жестком диске, добавьте имя каталога к целевому пути. Например, вы хотите скопировать содержимое «/ server / boodet / Documents» в каталог «резервные копии» на внешнем диске. Для этого нужно ввести команду:

rsync -r / server / boodet / Documents / / media / boodet / NEWHDD / backups /

Чтобы сохранить настройки файлов и разрешений, используйте параметр a (архив). С его помощью можно сохранить атрибуты файлов — даты модификации, права собственности на файлы, права доступа. Это пригодится, если вы планируете восстанавливать состояние сервера Linux из резервной копии целиком:

rsync -ra / server / boodet / Documents / / media / boodet / NEWHDD / backups /

Чтобы rsync перечислял файлы по мере их копирования, используйте параметр v:

rsync -rav / server / boodet / Documents / / media / boodet / NEWHDD / backups /

Если вы хотите видеть прогресс в ходе копирования каждого файла, используйте параметр p:

rsync -raP / server / boodet / Documents / / media / boodet / NEWHDD / backups /

Бэкап сервера Linux на внешний диск обычно происходит медленно. Чтобы ускорить процесс, можно использовать параметр z. Файлы будут сжиматься при передаче, но в целевом каталоге будут храниться в изначальном виде:

rsync -ravz / server / boodet / Documents / / media / boodet / NEWHDD / backups /

Бэкап Linux-сервера на NAS

Данные можно сохранять не только на внешний диск, но и в облако или на сетевое устройство хранения данных (NAS). Чтобы использовать сетевое расположение в качестве места копирования бэкапа Linux, укажите путь к облачному хранилищу или NAS в командной строке. Команды будут такими же, как и для внешнего жесткого диска.

Бэкап по SSH

Rsync поддерживает резервное копирование через SSH-соединение. Понадобится указать имя учетной записи пользователя и расположение SSH в командной строке. Здесь нужно использовать сетевое имя, но можно и IP-адрес. Обратите внимание на знак «:» между деталями SSH-соединения и началом сетевого пути на удаленной цепи:

rsync -ravz / server / boodet / Documents / boodet@online.local: / server / boodet / Backups /

Восстановление данных на Linux

Для восстановления файлов из дампа используйте команду restore. Полная резервная копия файловой системы восстановится, а последующие многоуровневые резервные копии будут храниться поверх нее. Отдельные файлы и поддеревья каталогов Linux-сервера можно легко восстановить из полных или частичных резервных копий.

восстановить -C [-cdHklMvVy] [-b размер блока] [-D файловая система] [-f файл] [-F скрипт] [-L лимит] [-s fileno] [-T каталог]

Чтобы восстановление соответствовало вашим целям, используйте различные параметры, которые обозначают буквами после команды restore, например:

a — чтобы восстановить все тома автоматически, начиная с 1;

h — чтобы извлечь фактический каталог, а не файлы. Это предотвращает иерархическое восстановление полных поддеревьев из дампа;

i — интерактивное восстановление файлов Linux Server . После прочтения информации о каталоге откроется графический интерфейс;

r — поднимает всю файловую систему.

Резервное копирование по расписанию

Чтобы создавать резервные копии Linux по расписанию, открываем файл crontab:

В примере мы настроим автоматическое резервное копирование, которое будет запускаться каждый день в 00:30. Для этого перед rsync-командой просто пишем время, например:

00 30 rsync -r / server / boodet / Documents / / media / boodet / NEWHDD /

Ctrl + O запишет ваши изменения в файл, а Ctrl + X закроет nano-редактор.

Источник

Настройка резервного копирования Linux-сервера за 5 минут

Передо мной возникла необходимость настроить резервное копирование на новом Linux-сервере, задачка эта оочень важная, но уж больно скучная: нужно написать и отладить скрипты, которые будут архивировать нужные папки (причем желательно делать инкрементальные архивы), базы данных, хранилища subversion, а затем переносить эти архивы на удаленный сервер. По этому я попробовал нагуглить готовое решение для этой задачки и в результате наткнулся на backup-manager — замечательный опенсорсный набор bash-скриптов, позволяющих:

• архивировать любые папки, в том числе и создавать инкрементальные архивы. В конфиге просто указывается список директорий, которые должны быть скопированы, а также «черный список» файлов, которые копироваться не будут.
• делать резервное копирование баз данных MySQL. В конфиге указываются логин и пароль mysql-юзера, имеющего доступ к базам, а всю остальную работу backup-manager делает сам.
• делать резервное копирование svn-репозиториев, причем бэкап делается не копированием папки с хранилищем, а с помощью команды svnadmin dump.
• шифровать архивы.
• копировать созданные архивы на удаленные сервера по FTP, SSH или (это самая важная для меня фича) в хранилище Amazon S3, а также записывать их на DVD.

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

Скачать можно отсюда: www.backup-manager.org/downloads, либо просто можно установить пакет backup-manager (пример для Debian):

aptitude install backup-manager

Кроме того, нужно учесть, что для копирования данных в хранилище Amazon S3 в системе должны быть установлены пакеты libnet-amazon-s3-perl и libfile-slurp-perl:

aptitude install libnet-amazon-s3-perl libfile-slurp-perl

Теперь остается только настроить запуск backup-manager по крону и можно спать спокойно.

Upd.
Все настройки хранятся в файле /etc/backup-manager.conf, вот основные его параметры:

# Папка, в которой архивы будут складываться локально
export BM_REPOSITORY_ROOT=»/var/archives»

# Используемые методы резервного копирования
export BM_ARCHIVE_METHOD=»tarball-incremental mysql svn»

# Далее для каждого из выбранных выше методов резервного копирования задаем настройки
# Список папок, содержимое которых будем бэкапить
BM_TARBALL_TARGETS[0]=»/etc»
BM_TARBALL_TARGETS[1]=»/boot»
BM_TARBALL_TARGETS[2]=»/var/www»
export BM_TARBALL_TARGETS

# Список исключений, то есть файлов в перечисленных выше папках, которые бэкапить не нужно
export BM_TARBALL_BLACKLIST=»/dev /sys /proc /tmp *imagecache*»

# Теперь указываем как часто делать мастер-бэкап и инкрементный бэкап
export BM_TARBALLINC_MASTERDATETYPE=»weekly»
export BM_TARBALLINC_MASTERDATEVALUE=»1″

# Для бэкапа MySQL баз данных указываем какие базы бэкапить и параметры mysql-юзера
export BM_MYSQL_DATABASES=»__ALL__»
export BM_MYSQL_ADMINLOGIN=»user»
export BM_MYSQL_ADMINPASS=»1234″

# Для бэкапа subversion-репозитория указываем путь к хранилищу
export BM_SVN_REPOSITORIES=»/var/repositories»

# Выбираем метод аплоада созданного бэкапа а удаленный сервер
# (еще есть варианты ftp, ssh, ssh-gpg, rsync)
export BM_UPLOAD_METHOD=»s3″

# Для копирования копий на Amazon S3 задаем имя корзины, access key и secret key
export BM_UPLOAD_S3_DESTINATION=»basket-name»
export BM_UPLOAD_S3_ACCESS_KEY=»ABC123″
export BM_UPLOAD_S3_SECRET_KEY=»DEF456″

Это самые основные настройки, в самом конфиге есть еще пара десятков параметров, все они подробно прокомментированы.

Источник

Простой способ резервного копирования Linux-сервера с выгрузкой файлов по FTP

Здравствуйте.
О важности регулярного резервного копирования уже сказано очень много слов. В этой статье мы предлагаем вниманию читателей примеры простых скриптов для бэкапа файлов и баз данных MySQL с последующей выгрузкой архивов на удаленный FTP-сервер.
Несмотря на то что мы в NQhost предлагаем решения по сохранению snapshot’ов VPS-контейнеров, процесс бэкапа собственными силами — безусловно важнейшая вещь.

Хозяйство

Виртуальный или физический сервер с установленной Linux-ОС, веб-сервером и базами данных MySQL.
Файлы веб-сервера располагаются в директориях
/home/site1
/home/site2
/home/site3

Задача

Создание скрипта для резервного копирования файлов и баз данных с сохранением на удаленном FTP-сервере и запуск его каждый день.

Решение

Для простоты примера работать мы будем из-под root`а, директория для хранения бэкапов файлов — /root/backup/server, а для дампов MySQL — /root/backup/mysql

Backup файлов

Здесь приводится пример скрипта для бэкапа файлов, для наглядности пояснения даны в квадратных скобках на русском языке.

#!/bin/sh
### System Setup ###
BACKUP=/root/backup/server

### FTP ###
FTPD=»/»
FTPU=»username» [имя пользавателя (логин) удаленного ftp-cервера]
FTPP=»megapassword» [пароль доступа к удаленному ftp-серверу]
FTPS=»my_remote_backup.ru» [собственно, адрес ftp-сервера или его IP]

### Binaries ###
TAR=»$(which tar)»
GZIP=»$(which gzip)»
FTP=»$(which ftp)»

## Today + hour in 24h format ###
NOW=$(date +%Y%m%d) [задаем текущую дату и время, чтобы итоговый файл выглядел в виде server-YYYYMMDD.tar.gz]

mkdir $BACKUP/$NOW
$TAR -cf $BACKUP/$NOW/etc.tar /etc [c целью сохранения настроек для простоты копируем весь /etc ]
$TAR -cf $BACKUP/$NOW/site1.tar /home/site1/
$TAR -cf $BACKUP/$NOW/site2.tar /home/site2/
$TAR -cf $BACKUP/$NOW/site2.tar /home/site3/

$TAR -zcvf $ARCHIVE $ARCHIVED

### ftp ###
cd $BACKUP
DUMPFILE=server-$NOW.tar.gz
$FTP -n $FTPS

Результатом работы данного скрипта будет созданный файл в директории /root/backup/server вида server-ГГГГММДД.tar.gz содержащий в себе tar-архивы директорий /etc, /home/site1, /home/site2 и /home/site3
Этот же файл будет загружен на FTP-сервер, который мы указали в начале скрипта.

Backup баз MySQL

Этим скриптом мы выгружаем базы данных MySQL (делаем т.н. «дампы). Каждая база выгружается в отдельный файл.

#!/bin/sh
# System + MySQL backup script
### System Setup ###
BACKUP=/root/backup/mysql

### Mysql ### [параметры доступа к нашим базам MySQL]
MUSER=»root»
MPASS=»megapassword»
MHOST=»localhost»

### FTP ###
FTPD=»/»
FTPU=»username» [имя пользавателя (логин) удаленного ftp-cервера]
FTPP=»megapassword» [пароль доступа к удаленному ftp-серверу]
FTPS=»my_remote_backup.ru» [собственно, адрес ftp-сервера или его IP]

### Binaries ###
TAR=»$(which tar)»
GZIP=»$(which gzip)»
FTP=»$(which ftp)»
MYSQL=»$(which mysql)»
MYSQLDUMP=»$(which mysqldump)»

## Today + hour in 24h format ###
NOW=$(date +%Y%m%d)

### Create temp dir ###

### name Mysql ###
DBS=»$($MYSQL -u $MUSER -h $MHOST -p$MPASS -Bse ‘show databases’)»
for db in $DBS
do

Источник

Резервное копирование и восстановление Linux сервера

Стратегия резервного копирования

Мир IT стремительно развивается, новые технологии берутся на вооружение, меняются принципы их использования, но одно правило, древнее как мир, не утратило своей актуальности: резервное копирование по правилу 3-2-1. Что оно из себя представляет:

(3) — создание минимум трёх копий данных. Чем больше тем лучше. Хорошей практикой является проверка резервных копий. Например, иногда развернуть её на тестовой площадке и убедиться в работоспособности резервной копии, ведь её наличие ещё не означает, что резервная копия не повреждена. Естественно, эти копии не следует держать в одном месте, и мы плавно переходим ко второму правилу.

(2) — данные должны быть размещены на двух разных носителях. Под носителями подразумеваются два разных автономных сервера, или площадки, куда копии будут делаться по очереди. Если одна из площадок выйдет из строя, у вас останутся резервные копии на второй.

(1) — одна копия данных должна находится вне стен вашей организации. Самый пессимистичный пункт, но он необходим. Одна копия должна храниться как можно дальше, на случай разного рожа ЧП (пожар, катаклизмы и т. д.)

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

Резервное копирование rsync

rsync является возможно лучшей утилитой для синхронизации данных локально или в удаленный каталог. Использование rsync довольно простое и обладает рядом преимуществ:

• умеет в синхронизацию файлов по дереву каталогов;
• передача данных в один поток;
• позволяет при передаче данных сохранять симлинки, хардлинки, метаданные файлов, а так же права на файлы\каталоги;
• работает локально и по SSH;

Синтаксис использования следующий:

Остановимся подробно на опциях, на наиболее часто используемых. Список не полный, при необходимости вы можете обратиться к man

-v — Выводит подробную информацию о статусе копирования;

-q — «тихое копирование» (quiet), с минимальным выводом;

-R — Рекурсивное копирование с сохранением относительного пути (однако, не сохраняет метаданные и права файлов);

-a — Рекурсиваное копирование с сохранением атрибутов файлов;

-l — Копировать symlink;

-H — Копировать hardlink;

-u — Опция позволяет не перезаписывать файлы с более свежей датой модификации;

-L — Копировать содержимое ссылок;

-p — Сохраняет права владельца файлов;

-g — Сохраняет группу;

-t — Сохраняет время модификации файла;

-e — Изменение протокола синхронизации. Например, при использовании SSH;

-W — полное копирование данных, инкрементация не применяется.

Настройка сервера rsync

Для начала установим утилиту из репозитория на локальном и удаленном хостах:

Для Debian: root@dedicated:

# apt-get -y install rsync

Для RHEL/CentOS: root@dedicated:

# yum -y install rsync

Сразу привыкаем делать правильно 🙂 Копировать от root не самая лучшая идея, для этого создадим локального пользователя rbak, и зададим ему права sudo на использование только определенного софта:

В открывшемся конфигурационном файле, в блоке «User privilege specification» добавьте следующую строку:

Давайте проверим результат. Как видим, прав на запуск fdisk нет, но выполнение указанной выше утилиты разрешено:

Таким образом, мы пользователю rbak (состоящему в группе rbak) разрешили выполнение rsync от sudo. Теперь создадим локальный каталог для бекапа, для примера, пусть это будет в каталоге /home/rbak, и зададим правильные права:

Теперь перейдем к редактированию главного конфигурационного файла, добавив в него параметры: путь к каталогу для резервного копирования, ip адрес, с которого можно подключаться, uid и gid пользователя

Запустите службу и добавьте её в автозагрузку:

Примечание: Внимательный читатель может задать вопрос, зачем мы добавляли пользователя в sudo, с правами запуска rsync, когда достаточно было создать пользователя и назначить ему права на каталог с будущими резервными копиями. В зависимости от того, какую стратегию резервного копирования вы выберете, хорошей практикой является копирование не «С» локального сервера на удаленный, а именно запуск rsync c удаленного, который по тоннелю ssh будет подключаться к серверу который бекапиться, и забирать необходимые данные.

Зачем это нужно: Представьте, что ваш сервер заражен вредоносным кодом. Попадая на машину, в большинстве случаев, ему не составит труда просканировать каталоги, получив в том числе доступ к серверу резервных копий по ssh-keys пользователя root или пользователя rsync.

Примеры использования rsync

Пожалуй, первая опция, которую следует запомнить, это —dry-run. Если вы не уверены в использовании той или иной опции, решим эмуляции позволит увидеть результат выполнения без внесения изменений на продакт площадке:

Локальное копирование (синхронизация) каталога:

Если копируется каталог с большим колличеством данных и вы желаете видеть прогресс копирование, можно использовать ключ —progress.

Скопируем каталог с нашего сервера на удаленный по ssh:

Из результата следует, что каталог синхронизировался на удаленный сервер, рекурсивно скопировав все подкаталоги с файлами. Удобство использования rsync так же в том, что файлы синхронизируются инкрементально. Давайте на наш локальный сервер добавим в альбом композицию под номером 11 и запустим команду повторно:

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

Синхронизация в обратную сторону, с удаленного хранилища в локальное, будет выглядеть следующим образом:

Если на удаленном сервере используется нестандартный порт для SSH соединения, укажите его:

Мы можем синхронизировать каталоги не полностью, а задать правило, по которому будет выполняться синхронизация c удаленного сервера по заданной маске. Допустим, нам нужно скопировать только конфиги c расширением *.conf:

С помощью опции —remove-source-files, после синхронизации данных на удаленный сервер, их можно автоматически удалить с локальной машины:

Допустим в локальном каталоге у нас 11 файлов, на удаленном хосте тоже 11, но локально мы удалили 1 файл. Синхронизировать необходимо существующее состояние каталога. Для этого существует опция —delete

rsync позволяет ограничить передачу файлов по размеру. Для этого используется опция —max-size, файлы превышающее его значение будут игнорироваться:

В зависимости от комплектующих, которое вы используете, может пригодиться ограничения по скорости копирования. Особенно это важно, если накопители на которые выполняется запись, ограничены в iops. С помощью опции —bwlimit можно ограничить скорость синхронизации, например, установив значение в 500 килобайт\секунда:

Если нам не требуется инкрементальная синхронизация, опция -W позволит выполнить полную синхронизацию каталога.

Что делать если нам необходимо с сервера rsync полключиться к удаленному серверу? Для этого в уже знакомом файле /etc/rsyncd.conf, в конце добавляем две строки:

В файл /etc/rsyncd.pass с новой строки пишем пользователей, и их пароли.

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

Резервное копирование Duplicity

Duplicity — это пакет, обеспечивающий версионное удаленное резервное копирование файлов на локальное или удаленное хранилище. При необходимости может быть настроенным зашифрованным с цифровой подписью. Важной особенностью является возможность копировать данные черзез SFTP, FTP, что делать rsync «без костылей» не умеет.

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

Установка и общие команды

Для примера, создадим резервную копию нашего сайта WordPress в каталог /home/backups/

—no-encryption — без шифрования;

—volsize=1024 — размер тома, сохраненный в /home/backups/;

—include=/var/www/wordpress — каталог, для которого создается бекап. При необходимости в одну строку вы можете указать несколько —include;

exclude=/** — исключить для резервирования все остальные файлы и каталоги;
file:// — локальный путь (При удаленном копировании на ftp, опция имела бы вид ftp://)

Далее нужно выполнить инкрементальный бекап. Для этого в целевом каталоге создадим info.php и запустим команду с опцией incremental

В каталоге /home/backups/ будут созданы полный и инкрементальный архивы *.gz

Отобразить резервные копии которые были нами созданы:

Выполним верификацию данных и последнюю версию резервной копии:

Теперь давайте выполним в каталог тестовый каталог /tmp/restore/ несколько примеров восстановления:

Успешным выполнением есть следующее:

Проверяем каталог /tmp/restore/, в котором от корня скопировано дерево каталогов нашего сайта (/tmp/restore/var/www/wordpress). Восстановился последний инкрементальный бекап с файлом info.php

Выполним проверку по количеству файлов:

Восстановить определенный каталог можно командой (аналогично можно указать путь к файлу). Удалим каталог plugins и запустим восстановление

Мы так же можем восстановить бекап десятидневной давности. Для этого существуют ключи «-t 10D»:

10D — количество дней. Другие возможные опции: секунды (s), минуты (m), часы (h), дни (D), недели (W), месяцы (M), годы (Y).

Удалить бекапы старше 14 дней:

Удаленное копирование

Установим необходимые зависимости:

Команда удаленного копирования на FTP будет выглядеть так:

где: cf900585 — логин; yq77q1Ad14hD — пароль; backup60.freehost.com.ua — сервер резервных копий; 21 — порт.

В целом, особенно использование duplicity удобно с помощью скриптов, так как необходимо указывать множество параметров. В данном примере мы рассмотрим, как можно скопировать наш каталог wordpress и на удаленный ftp сервер. И настроить автоматическое удаление резервных копий старше 14 дней.

Если на удаленном FTP сервере нужно явно указать каталог, создайте переменную $DESTFOLDER

Ставим его на выполнение и зппускаем:

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

Копирование диска с помощью dd

При резервном копировании так же очень полезна будет стандартная утилита dd (dataset definition). С помощью этой простой утилиты можно создать полный клон диска сервера. При этом он будет занимать такое же место, как и исходный носитель. Другими словами, если, например, диск /dev/vda1 имеет емкость 20Gb, с которых информации на 15Gb, то образ все равно будет занимать 20Gb, куда по блокам будет выполнено полное зеркалирование исходного носителя.

где: if — исходный носитель; of — куда копируем (имя копии). Соответственно, при восстановлении, меняем местами if и of, указывая правильные пути для восстановления.

Команда dd имеет на вооружении некоторый опции, рассмотрим некоторые из них:

bs=8M — по умолчанию копирование выполняется по 512 байт «за раз», ускорить выполнения копирования можно увеличением кеша bs. Однако, увлекаться с ускорением зеркалирования не стоит, рекомендованное значение — 2-4-8М;
sync — данные которые повреждены будут заменены на нули;

noerror — копирование будет выполняться даже при наличии бэд-блоков на носителе;
status=progress — отображает прогресс копирования носителя;

Выполнить удаленное копирование по SSH:

Выполнить удаленное копирование по SSH с максимальным сжатием:

Команда dd полезна не только при резервном копировании. Если диски ранее использовались в RAID массивах, на них могут остаться данные которые обязательно нужно удалить. Полностью «занулить» диск можно командой:

Удалить данные можно частично. Следующая команда удалит первые 20Mb

Возможно нужно затереть еще конец диска , т.к. данные о разметке, raid могут храниться еще в конце диска. Смотрим общее кол-во секторов:

Чистим конец диска , указываем с какого сектора начинать (я отнимаю приблизительно 20 — обычно хватает)

seek — опция указывает на то, сколько необходимо пропустить количество байт (obs-size блоков) в начале вывода;

C полным перечнем опций можно ознакомиться в man

Заключение

Мы рассмотрели три простые, но в тоже время мощные утилиты, которые следует взять на вооружение каждому администратору. Важно так же следовать стратегии «3-2-1». С нашей стороны мы выполняем нашу часть обязательств, предоставляя бесплатное место для хранения резервных копий на FTP сервере, в размере 20Gb для виртуальных VPS серверов и физических серверов, куда вы можете самостоятельно настроить резервное копирование. Кроме этого мы делаем недельный бекап виртуальных VPS серверов, что позволяет откатить состояние сервера на исходную дату в несколько минут. Так же мы предлагаем обратить внимание на дополнительное высоконадежное облачное хранилище CEPH, которое мы предоставляем. Хранилище использует технологию, позволяющую хранить информацию на распределенном компьютерном кластере с тройным дублированием данных за вполне доступную сумму. Стоимость за 1 Gb составляет 2.68 грн. в месяц. Даже если ваша инфраструктура расположена в другом дата-центре или личной серверной, заказав самый простой VPS, и подключив к нему облачное хранилище CEPH, вы получаете отказоустойчивый сервер для хранения резервных копий, который позволит обеспечить надежность вашей инфраструктуры по стратегии 3-2-1.

Источник