Чтобы использовать параметр жесткой ссылки rsync для удаленного резервного копирования файлов, чтобы удаленный сервер резервного копирования мог хранить несколько версий резервных копий, каталог link-dest и целевой каталог должны находиться на одном удаленном диске. Но опция 'rsync --link-dest' принимает только локальный путь. Чтобы запустить сценарий с сервера, на котором необходимо создать резервную копию каталога, сначала необходимо подключиться по SSH к серверу резервного копирования, а затем с сервера резервного копирования выполнить команду rsync, как показано ниже:
ssh root@12.34.56.7 'rsync -a --delete --rsh "ssh -l root -i /root/.ssh/key2" --link-
dest=backupDict.1 19.2.2.1:/mnt/mountDict backupDict'
Есть ли менее сложный способ резервного копирования файлов с жесткой ссылкой?
Также я получил журналы ошибок и зависание гипервизора во время обработки резервного копирования, при создании снимка виртуальной машины и монтировании снимка lv в качестве исходного каталога. Снимок и монтирование виртуальной машины можно найти, если не использовать метод жесткой ссылки rsync. Есть способ исправить?
Mar 10 02:36:59 kvm kernel: BUG: Bad page map in process udevd pte:800000081ad43645 pmd:409f37067
Mar 10 02:36:59 kvm kernel: addr:00006aff4f837000 vm_flags:00100173 anon_vma:ffff88081f7dc448 mapping:(null) index:7fffffff1
Mar 10 02:37:02 kvm kernel: Pid: 5091, comm: udevd Not tainted 2.6.32- 358.18.1.el6.x86_64 #1
Mar 10 02:37:03 kvm kernel: Call Trace:
Mar 10 02:37:03 kvm kernel: [<ffffffff8113ef18>] ? print_bad_pte+0x1d8/0x290
Mar 10 02:37:03 kvm kernel: [<ffffffff8111b970>] ? generic_file_aio_read+0x380/0x700
Mar 10 02:37:03 kvm kernel: [<ffffffff8113f03b>] ? vm_normal_page+0x6b/0x70
Mar 10 02:37:03 kvm kernel: [<ffffffff8114179f>] ? unmap_vmas+0x61f/0xc30
Mar 10 02:37:03 kvm kernel: [<ffffffff811476d7>] ? exit_mmap+0x87/0x170
Mar 10 02:37:03 kvm kernel: [<ffffffff8106b50c>] ? mmput+0x6c/0x120
Mar 10 02:37:03 kvm kernel: [<ffffffff811889a4>] ? flush_old_exec+0x484/0x690
Mar 10 02:37:03 kvm kernel: [<ffffffff811d9700>] ? load_elf_binary+0x350/0x1ab0
Mar 10 02:37:03 kvm kernel: [<ffffffff8113f3ff>] ? follow_page+0x31f/0x470
Mar 10 02:37:03 kvm kernel: [<ffffffff811446e0>] ? __get_user_pages+0x110/0x430
Mar 10 02:37:03 kvm kernel: [<ffffffff811d7abe>] ? load_misc_binary+0x9e/0x3f0
Mar 10 02:37:03 kvm kernel: [<ffffffff81144a99>] ? get_user_pages+0x49/0x50
Mar 10 02:37:03 kvm kernel: [<ffffffff81189fa7>] ? search_binary_handler+0x137/0x370
Mar 10 02:37:03 kvm kernel: [<ffffffff8118a4f7>] ? do_execve+0x217/0x2c0
Mar 10 02:37:03 kvm kernel: [<ffffffff810095ea>] ? sys_execve+0x4a/0x80
Mar 10 02:37:03 kvm kernel: [<ffffffff8100b4ca>] ? stub_execve+0x6a/0xc0
Mar 10 02:37:03 kvm kernel: Disabling lock debugging due to kernel taint
Ого.
Link-dest может принимать только локальный путь (как и жесткие ссылки в традиционных файловых системах), потому что они фактически должны указывать на точно такой же индекс. Каждый раз, когда вы обращаетесь к этому inode, вы увеличиваете на нем счетчик открытий (что предотвращает его очистку), и когда вы складываете его через пару процессов ssh и бросаете большой нетерпеливый снимок виртуальной машины без очереди, это .... , Я ожидал, что все сломается.
У меня есть пара вопросов: - Почему именно вы монтируете снимок LV вместо исходного диска? Космос? Вы могли бы выполнить щелчок прямо через туннель ssh, но, вероятно, было бы разумнее щелкнуть, а затем rsync. - Почему такая странная зависимость от жесткой ссылки, когда она вызывает у вас проблемы с источником?
Я делаю что-то не совсем похожее с некоторыми ящиками виртуальных машин, но с несколькими nas4free (то есть ящиками ZFS), которые являются целями iScsi для хостов виртуальных машин. Снимки ZFS выполняются мгновенно, настолько устойчивы, насколько у меня есть место, знакомо мне. Я избегаю репликации ZFS, как чумы удаленных ссылок, я бы предпочел удаленно привязать ближнюю линию и rsync отдельные файлы также а затем зафиксируйте это на другом конце, это немного усложняется с загруженными виртуальными машинами (например, серверами Exchange) и немного быстро и непоследовательно, но есть другие способы обойти это. Как бы то ни было, у большинства моих клиентов в день есть 15-минутные локальные снимки, и на следующий день NAS в моем офисе догоняют ... иногда намного быстрее. Я могу появиться на месте с новой машиной или удаленно развернуть их виртуальную машину, и они действительно не знают разницы. Я знаю, что использование оборудования - не идеальный ответ, но у вас действительно не будет той боли, которую вы делаете сейчас (похоже, вы действительно рискуете обоими сторонами и не защищаете ни то, ни другое). Я бы определенно посмотрел на iScsi NAS, HDFS, возможно DRBD, репликации openstack-y vm на три + машины. (Я не знаю, насколько ты большой), если бы я был на твоем месте.
Но также постарайтесь разбить работу на более мелкие части.
О, и никогда не стоит недооценивать пропускную способность универсала, полного кассет.