rsync :Копировать символические ссылки как обычные файлы
Большинство служб используют системный журнал, поэтому достаточно перезапустить системный журнал или соответствующий rsyslog. Например, в Debian
service rsyslog restart
rsync обычные файлы, затем отдельно найдите все ссылки, перечислите их в файле и создайте все файлы ссылок один за другим
#!/bin/bash
$SRCDIR="/backup/";
$SRCSERVER="user@example.com";
$DEST=".";
rsync -rtpEv "$SRCSERVER:$SRCDEST" $DEST;
ssh SRCSERVER "stat -c %N \`find $SRCDIR -type l\` 2> /dev/null" > links;
$MUNGED = ".munged";
while read p; do
file=$(echo $p | awk -F ' ' '{print $1}' | sed "s/^\`/;s/'$//");
dest=$(echo $p | awk -F ' ' '{print $3}' | sed "s/^\`//;s/'$//");
echo $dest > "$file$MUNGED";
done < links;
(не уверен в синтаксисе моего bash, я запускал все это вручную)
То, что вы хотите, невозможно напрямую:
- Вы не можете преобразовать символическую ссылку в файл с суффиксом имени, например
munged - Вы можете преобразовывать символические ссылки в обычные файлы (
--fake-super), но связанные с ними метаданные, позволяющие преобразовывать их обратно в символические ссылки, не могут храниться в файловой системе exFAT
Другие возможности
- Опция
--munge-linksоставляет символические ссылки как символические ссылки, но исправляет значение символической ссылки, так что оно не может быть действительным в целевой системе. Бесполезно для файловой системы exFAT - Вы можете использовать
--copy-linksдля расширения символической ссылки на фактический файл. Вероятно, это не то, что вам нужно, поскольку информация о символической ссылке теряется и не может быть восстановлена при возврате данных в исходную систему .
Единственное другое решение, которое я вижу, это создать большой файл в целевой системе, который можно смонтировать как родную файловую систему Linux, такую как ext4. Затем вы можете отправлять свои резервные копии в эту файловую систему и пользоваться ее дополнительными функциями сверх ограниченного набора в exFAT.
Если файлы не должны быть доступны для чтения или изменения напрямую, а просто восстанавливаются как единое целое, простое решение состоит в том, чтобы заархивировать их с помощью tarили подобного.
Если файлы не должны быть доступны для прямого чтения из резервной копии, но вы хотите иметь возможность обновлять резервную копию и у вас есть свободное место на диске, вы можете использовать Git для архивировать данные. В качестве бонуса вы сможете восстановить старые версии.
cd /path/to/back/up
git init.
git commit -a
git clone --bare.git /media/external-disk/my-site.git
Git хранит символические ссылки, но не разрешения. Если права доступа к файлам имеют значение, вы можете использовать etckeeper . Он охватывает Git (или другую систему контроля версий )и хранит метаданные файла в отдельном файле.
Если файлы не должны быть доступны из системы, отличной от -Linux, и у вас есть хорошая оценка их общего размера, вы можете создать образ файловой системы ext4 и цикл -монтировать ит. Примерно так для первоначальной подготовки:
truncate -s 42G /media/external-disk/linux.fs
mkfs.ext4 -F /media/external-disk/linux.fs
Затем использовать образ файловой системы:
sudo mkdir /media/external-linux
sudo mount -o loop /media/external-disk/linux.fs /media/external-linux
sudo rsync -ax / /media/external-linux/my-site-backup
sudo umount /media/external-linux
Потенциальным подходом может быть уровень файловой системы, использующий отдельный файл для хранения метаданных, которые не поддерживает базовая файловая система. [Upfs] (Вы можете попробовать Upfs , он делает это, но, к сожалению, он не поддерживается.
(Давным-давно был популярен умсдос ; он позволял хранить файлы Linux в файловой системе FAT, которая не поддерживала символические ссылки, разрешения, имена файлов длиннее 8 символов плюс расширение из 3 -символов и т. д. К сожалению, он не совместим с FAT32 или exFat.)