Я покупаю внешний жесткий диск для резервного копирования компьютеров в моем доме (наконец-то !!). Я надеюсь использовать rsync. Я видел пример, который делает (или кажется, делает) именно то, что я хочу. Что-то вроде этого:
rsync -aE --delete /path/to/what/I/want/to/backup /Volumes/FW200/Backups
Однако при просмотре документации и примеров rsync все стало выглядеть НАМНОГО сложнее. Сети, демоны и жаргон, о боже!
Я предполагаю, что ничего из этого не требуется, если я просто выполняю синхронизацию с компьютера на внешний диск, подключенный к Firewire. Я ошибаюсь, предполагая это? Неужели все будет сложнее, чем эта безобидная команда?
Я использую rsync со следующими флагами, которые легко запомнить как 'glop', 'trunc' и 'v'.
rsync -gloptrunc $srcdir $dstdir
Краткое руководство:
Я всегда запускаю вышеуказанное, чтобы убедиться, что это работает, а затем удаляю флаг «n», когда я доволен результатами.
Ключевые особенности вышеперечисленных комбинаций:
Я использую это, чтобы синхронизировать две машины или синхронизировать подкаталоги (например, резервное копирование на USB-накопитель).
Как уже говорилось в одном из других сообщений, контрольная сумма может быть отключена, если вы имеете дело с локальными дисками.
В некоторых редких случаях мне приходилось добавлять дополнительные параметры для учета изменений в учетных записях входа на удаленных машинах, изменения портов и даже указания того, где находится rsync на удаленном хосте ... но они не применимы напрямую к вашему вопрос.
Rsync отлично работает с локальными дисками. Однако, если он обнаруживает локальные пути, он автоматически переходит в режим --whole-file, который не копирует различия, а просто копирует исходный файл поверх файла назначения. Rsync по-прежнему будет игнорировать файлы, которые вообще не изменились. Когда пропускная способность между источником и местом назначения высока (например, два локальных диска), это намного быстрее, чем чтение обоих файлов с последующим копированием только измененных битов.
Ничего из этого не требуется, вы можете использовать rsync без каких-либо демонов или любой другой конфигурации. ПРОСТО ПРЕКРАСНО!
Просто используйте команду rsync, и все готово.
Судя по пути в вашей команде rsync, прав ли я, думая, что вы используете Mac OS X?
Лично я бы выбрал Time Machine (если вы используете Leopard) или Carbon Copy Cloner (http://www.bombich.com/software/ccc.html), который использует rsync.
Намного проще, чем пытаться исправить собственный сценарий. Одним из преимуществ является то, что Time Machine и CCC предоставляют вам инкрементные резервные копии.
Пример, который вы использовали, выглядит так, как будто он отлично подходит для резервного копирования.
Одна вещь, которую вы, возможно, захотите рассмотреть при использовании rsync, - это использовать параметр --link-dest. Это позволяет вам хранить несколько резервных копий, но использовать жесткие ссылки для любых неизмененных файлов, эффективно заставляя все резервные копии занимать пространство инкрементальной. Пример использования:
rsync -aE --link-dest=/mnt/external_disk/backup_20090612 dir_to_backup \
/mnt/external_disk/backup_20090613
Это предполагает, что у вас есть резервная копия, датированная 12 июня, и вы хотите создать новую 13 июня. Возможно, вы захотите опустить параметр -v, если не хотите распечатывать каждый файл.
Это действительно зависит от того, используете ли вы базы данных или нет. Rsync сделает снимок каждого файла и проигнорирует любые промежуточные записи. Если вы хотите создать резервную копию базы данных, вам следует подумать о настройке фильтра игнорирования и запуске инструментов дампа базы данных перед rsync.
Ваша команда в том виде, в котором она написана, должна работать, однако вы можете посмотреть программу под названием rsnapshot, которая построена на основе rsync и хранит несколько версий файлов, чтобы вы могли вернуться и посмотреть на вещи, как они были на прошлой неделе или в прошлом месяце. Конфигурация довольно проста, и она действительно хороша для оптимизации пространства, поэтому, если у вас не много оттока, она не займет намного больше места, чем одна резервная копия.
Вы не упомянули свою операционную систему. Исходя из предположения, что это ОС на базе * nix, ваша команда хороша.
Однако, если один или оба диска имеют формат NTFS, доступ к ним осуществляется из * nix или даже из Windows с помощью Mobaxterm / cygwin, то дополнительные функции rsync не будут работать с rsync -a (archive flag)
Если задействованы диски NTFS, вы можете использовать:
rsync -rvh --size-only --delete /path/to/what/I/want/to/backup /Volumes/FW200/Backups
Загрузите клиент Mobaxterm ssh, чтобы использовать функции rsync в Windows.
Вот это больше информации при использовании rsync с NTFS-дисками
Я пробовал использовать rsync для резервного копирования, но это закончилось беспорядком. rsync лучше подходит для «синхронизации», чем для резервного копирования. И сравнивать большие файлы можно бесконечно.
Я немного исследовал и попробовал несколько (в основном тестировал всех из резервной копии поиска apt-cache в ubuntu).
Наконец я закончил с 'backup2l - Инструмент резервного копирования / восстановления, не требующий особого обслуживания », это просто. Мне нравится, как он управляет планированием и ротацией (по уровням). Я запускаю его всякий раз, когда подключаю внешний USB-накопитель из командной строки, но вы также можете автоматизировать его.
Попробуй дирвиш сделать резервную копию. http://www.dirvish.org/
Он использует жесткие ссылки из rsync в так называемых хранилищах. Вы можете сохранить столько старых дампов, сколько может вместить USB-диск. Или настроить его в автоматическом режиме.
Как только вы поймете идею dirvish, его будет удобнее использовать, чем rsync со всеми его параметрами.
Я нахожу решение для компьютера под управлением Windows: http://www.itefix.no/i2/node/10650
Чтобы скопировать раздел D: \ на внешний диск K: \
rsync -aE --delete --progress /cygdrive/d/* /cygdrive/k
Я не использую rsync с локальными дисками, но Rsync прекрасно подходит для синхронизации, клонирования, резервного копирования и восстановления данных между сетевыми системами Linux. Фантастический инструмент с поддержкой сети Linux, на изучение которого стоит потратить время. Узнайте, как использовать rsync с жесткими ссылками (--link-dest =), и жизнь наладится.
Однако я обнаружил, что rsync не так полезен для локальных дисков.
По моему опыту, во имя скорости Rsync автоматически изменяет многие рабочие параметры, когда rsync считает, что обнаружил два локальных диска. Что еще хуже. То, что считается «локальным» с точки зрения rsync, иногда может быть не таким уж локальным. В одном из примеров rsync видит подключенный сетевой ресурс SMB как локальный диск. Можно поспорить и быть правым, объяснив, что в этом случае для rsync как экземпляра программы все диски являются «локальными», но это упускает суть.
Дело в том, что сценарии, которые работают должным образом при использовании между локальным и удаленным дисками, не работают должным образом, когда используется один и тот же сценарий, когда rsnyc видит пути к данным как два локальных диска. Кажется, что многие параметры rsync изменены или не работают должным образом при работе со всеми локальными дисками. Обновление файлов может замедляться до обхода, если один из «локальных» дисков является сетевым SMB-ресурсом или большим медленным USB-накопителем.
Например, с опцией «cwrsync -av / local / files / / mountSMBshare / files» и без опции -c (контрольная сумма), где необходимость передачи должна определяться размером и датой файла со всеми локальными дисками, я вижу целые файлы, скопированные между источником и место назначения, когда файлы даже не изменились. Это бесполезное поведение, когда один «диск» является более медленным сетевым ресурсом SMB, а другой - медленным USB-накопителем NTFS. Было бы намного лучше использовать ssh на общем сервере SMB, но это не всегда возможно, и многие ненавистные элементы Windows являются частью повседневной коммерческой жизни.
Я бы предпочел, чтобы работа rsync была согласованной, независимо от «местоположения» дисков, и просто предоставляла пользователю возможность вызывать «локальную» операцию, когда преимущество в скорости считалось доступным и полезным. По моему скромному мнению, это будет более последовательная операция, которая сделает rsync более простым в использовании и более функциональным.