
У меня есть внешний жесткий диск на 1 ТБ, который я использую для резервного копирования всего моего компьютера. Прямо сейчас я настроил резервное копирование каждой из папок на моем компьютере, то есть /home, /usr и т. д. (За исключением /media, очевидно, так как это местоположение будет включать мой жесткий диск.) Причина этого в обширном резервном копировании, когда у меня были файлы в /etc или /usr, которые были повреждены, и затем мой дисплейный сервер внезапно перестал работать. Мне пришлось переустановить Ubuntu. Но это не имеет значения...
Я пользуюсь Ubuntu уже довольно давно, но до сих пор не понимаю, что означает каждая из этих папок. Сейчас, каждый раз, когда duplicity пытается сделать резервную копию, она застревает на определенном файле в /proc. Используя nautilus, он показывает, что файл имеет размер 0B и пуст, когда его открывают с помощью gedit. Резервная копия висит там довольно долго (не менее 15 минут) и в конечном итоге сообщает, что резервная копия не удалась.
Какие у меня есть варианты? Удалить все резервные копии с жесткого диска и попробовать еще раз? /proc не подлежит резервному копированию? Есть ли другая программа, кроме программы резервного копирования по умолчанию (duplicity или deja-dup, кажется, она так называется), которую мне следует использовать для такого обширного резервного копирования?
Спасибо!
решение1
/proc — это виртуальная файловая система, которая представляет состояние работающей системы, включая процессы и их карты виртуальной памяти, поэтому, да, нецелесообразно делать ее резервную копию, если только вы не отлаживаете ядро или что-то в этом роде. Другие подобные виртуальные файловые системы только для времени выполнения — это /sys, /run и /dev.
Учитывая, что ваша существующая резервная копия содержит некоторый мусор из /proc и, возможно, других компонентов файловой системы, когда вы в последний раз пытались, я бы по крайней мере удалил эти компоненты резервной копии, если вы можете, и попробовал бы снова, на этот раз без них. Deja-dup должен быть в порядке (лично я все еще использую rsync в командной строке, исходя из того, что я узнал в свое время).