Большая часть пользователей компьютеров Apple пользуются встроенным в Mac OS X решением для резервного копирования своих данных — Time Machine (TM). Я, однако, принадлежу к меньшинству, которое не пользуется «машиной времени».
Дело в том, что мне нужен бэкап по сети, а по сети Time Machine умеет копировать данные либо на Time Capsule, либо на общую папку, расшаренную на компьютере под управлением Mac OS X Leopard (и выше). Time Capsule я покупать не собираюсь, потому что она мне не внушает доверия, а другого мака в доме нет. Существуют различные хаки, при помощи которых можно заставить TM записывать резервные копии в любую сетевую папку, но у всех этих хаков есть побочные эффекты, бороться с которыми как-то не хочется. Поэтому — rsync, rsync и ещё раз rsync. Однако Apple не была бы Apple, если бы в духе заботы о пользователе не разложила на этом пути грабли, с которыми мы сейчас и будем бороться :)
Грабли заключаются в том, что в комплекте с Mac OS X поставляется очень странная версия rsync. Давайте посмотрим на неё внимательнее при помощи команды rsync --version:
Во-первых, она очень древняя (текущая версия — 3.0.7 — отличается усовершенствованным алгоритмом сравнения файлов и работает быстрее). Во-вторых, эппловский rsync собран с поддержкой метаданных файловой системы HFS+ и поддерживает специальный ключ -E для сохранения этих самых метаданных… но при этом на другом конце должна быть такая же «модифицированная» версия rsync. То есть «получателем» резервной копии опять же может выступать только компьютер с Mac OS X (Tiger или выше).
Не беда, эта проблема по большей части решается. Для начала мы скомпилируем на маке последнюю версию rsync (у вас должен быть установлен Xcode).
Загружаем исходные тексты:
Применяем релевантные патчи:
Теперь собираем:
Проверяем, что у нас получилось:
Теперь необходимо скомпилировать rsync на Linux-машине, которая будет использоваться для бэкапа, с применением патча fileflags, но БЕЗ патча crtimes! В Ubuntu 9.10 для этого надо сначала установить «средства производства»:
Делаем тестовый прогон:
Осталась только одна проблема: при попытке сделать бэкап на ext3-раздел, rsync ругнётся на то, что расширенные атрибуты файлов не помещаются в отведённое под них пространство. Для решения этой проблемы я отформатировал диск, на который производится бэкап, в XFS.
Основной недостаток данного метода заключается в том, что он не сохраняет атрибуты времени создания и модификации файла. Впрочем, для меня это некритично, потому что мне удалённый бэкап нужен не для создания загрузочной копии системного диска, а для обеспечения сохранности дорогих моему сердцу документов.
rsync хорош и тем, что можно написать скрипт и регулярно запускать его cron'ом. В этом случае резервное копирование будет осуществляться без вашего вмешательства. Но это уже тема для отдельной записи…
Дело в том, что мне нужен бэкап по сети, а по сети Time Machine умеет копировать данные либо на Time Capsule, либо на общую папку, расшаренную на компьютере под управлением Mac OS X Leopard (и выше). Time Capsule я покупать не собираюсь, потому что она мне не внушает доверия, а другого мака в доме нет. Существуют различные хаки, при помощи которых можно заставить TM записывать резервные копии в любую сетевую папку, но у всех этих хаков есть побочные эффекты, бороться с которыми как-то не хочется. Поэтому — rsync, rsync и ещё раз rsync. Однако Apple не была бы Apple, если бы в духе заботы о пользователе не разложила на этом пути грабли, с которыми мы сейчас и будем бороться :)
Грабли заключаются в том, что в комплекте с Mac OS X поставляется очень странная версия rsync. Давайте посмотрим на неё внимательнее при помощи команды rsync --version:
rsync version 2.6.9 protocol version 29
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
inplace, IPv6, 64-bit system inums, 64-bit internal inumsВо-первых, она очень древняя (текущая версия — 3.0.7 — отличается усовершенствованным алгоритмом сравнения файлов и работает быстрее). Во-вторых, эппловский rsync собран с поддержкой метаданных файловой системы HFS+ и поддерживает специальный ключ -E для сохранения этих самых метаданных… но при этом на другом конце должна быть такая же «модифицированная» версия rsync. То есть «получателем» резервной копии опять же может выступать только компьютер с Mac OS X (Tiger или выше).
Не беда, эта проблема по большей части решается. Для начала мы скомпилируем на маке последнюю версию rsync (у вас должен быть установлен Xcode).
Загружаем исходные тексты:
cd ~/Desktop
curl -O rsync.samba.org/ftp/rsync/src/rsync-3.0.7.tar.gz
tar -xzvf rsync-3.0.7.tar.gz
rm rsync-3.0.6.tar.gz
curl -O rsync.samba.org/ftp/rsync/src/rsync-patches-3.0.7.tar.gz
tar -xzvf rsync-patches-3.0.7.tar.gz
rm rsync-patches-3.0.7.tar.gz
cd rsync-3.0.7Применяем релевантные патчи:
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diffТеперь собираем:
./prepare-source
./configure
make
sudo make installПроверяем, что у нас получилось:
melchior:~ pavel$ /usr/local/bin/rsync --version
rsync version 3.0.7 protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: rsync.samba.org
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, no iconv, symtimes, file-flags
Теперь необходимо скомпилировать rsync на Linux-машине, которая будет использоваться для бэкапа, с применением патча fileflags, но БЕЗ патча crtimes! В Ubuntu 9.10 для этого надо сначала установить «средства производства»:
sudo apt-get install build-essential
sudo apt-get build-dep rsyncДелаем тестовый прогон:
/usr/local/bin/rsync -aHAXxzv --protect-args --fake-super --rsync-path="/usr/local/bin/rsync" ~/Documents/ pavel@192.168.1.5:/home/pavel/backupОсталась только одна проблема: при попытке сделать бэкап на ext3-раздел, rsync ругнётся на то, что расширенные атрибуты файлов не помещаются в отведённое под них пространство. Для решения этой проблемы я отформатировал диск, на который производится бэкап, в XFS.
Основной недостаток данного метода заключается в том, что он не сохраняет атрибуты времени создания и модификации файла. Впрочем, для меня это некритично, потому что мне удалённый бэкап нужен не для создания загрузочной копии системного диска, а для обеспечения сохранности дорогих моему сердцу документов.
rsync хорош и тем, что можно написать скрипт и регулярно запускать его cron'ом. В этом случае резервное копирование будет осуществляться без вашего вмешательства. Но это уже тема для отдельной записи…