LINUX.ORG.RU

Переход на Linux. Бэкап\восстановление пакетов\документов. Работа с ntfs

 , , , ,


0

1

Сейчас являюсь пользователем Windows. Собираюсь использовать Linux в качестве основной ОС. Работа с системой\файлами организована следующим образом:

1) На компьютере установлено 2 жестких диска: 1 - системный, 2 - под данные. Обозначим их соответственно как HDD1(SYSTEM) и HDD2(Data). Данные(документы, музыка, коллекция программ) копятся. Ненужное отсеивается. Нужное помещается в каталог HDD2\Back, расположенную в корне диска HDD2(Data).
2) Есть внешний жесткий диск. Обозначим как HDB(Backup). Периодически делается ручной бекап каталога HDD2\Back с диска HDD2 в каталог HDB\Back на диск HDB. Чтобы экономить время я копирую только измененные\добавленные файлы(я помню что добавил\поменял).

После первых двух действий(помещение файлов в HDD2\Back, копирование в HDB\Back) идет проверка по следующему алгоритму:
Я сравниваю содержимое каталогов HDD2\Back и HDB\Back по размеру и количеству файлов\каталогов. Если размер и количество файлов\каталогов совпадает, то ничего не забыл скопировать.

К сожалению данный алгоритм не подходит для Linux, поскольку он выводит разные размеры каталогов. Эта проблема встречается как в Ubuntu, OpenSuse, так и в других дистрибутивах. Похоже, что проблема как-то связана с Alternate Data Streams и ntfs-3g.

Для справки при сравнения размера каталогов обе системы выдают следующее:
Windows 7 (HDD2\Back)
Тип: Папка с файлами
Расположение: N:\
Размер: 204 ГБ (219 378 661 023 байт)
На диске: 204 ГБ (219 437 273 088 байт)
Содержит: Файлов: 26 783; папок: 2 307
Windows 7 (HDB\Back)
Тип: Папка с файлами
Расположение: А:\
Размер: 204 ГБ (219 378 661 023 байт)
На диске: 204 ГБ (219 437 273 088 байт)
Содержит: Файлов: 26 783; папок: 2 307

Linux (HDD2\Back)
$ du -s -b /media/HDD/Back/
219389240991 /media/HDD/Back/
Linux (HDB\Back)
$ du -s -b /media/HDB/Back/
219388786335 /media/HDB/Back/

Как видно, размеры в Windows 7 сравнимы, а в Linux - нет. Каталоги не изменялись на протяжении всего изменения размеров(вначале смотрел в Linux, потом в Windows). Размеры в Windows 7 получены через свойства, в Linux через команду du -s -b. Жду решений, желательно с примерами.

P.S. Понимаю скажете, что такая проверка не совсем правильная. Правильнее бы было использовать в качестве проверки что-то вроде контрольных сумм и т.д. Или вообще использовать сторонний софт для синхронизации данных. Но мне ручное копирование и указанный выше алгоритм в принципе устраивает, в связи с чем я жду и приветствую решения для локального копирования данных \ восстановления данных используя стандартные средства системы Linux(консольный cp, du и т.д.). Но буду рад и услышать про надежные средства резервного копирования в Linux\Windows(как дополнительно). Что касается решений со сменой самой файловой системы NTFS на другую, то это нежелательные решения, поскольку периодически диски будут нужны именно с файловыми системами NTFS. при этом системный диск (HDD1(SYSTEM)) может быть с любой файловой системой. Ubuntu(12.04.4 gnome\kde)\OpenSuse(12.3 KDE) те дистрибутивы которые будут рассматриваться в первую очередь, как дистрибутивы для домашнего пользования, в связи с чем могут быть специфические решения для этих систем.

P.S. Если будет полезно: до этого замечал такую вещь как изменение в выводе команды du до посещения каталога через Dolphin и после посещения(без изменения файлов и каталогов). Судя по всему он оставляет там какую-то информацию.

жду и приветствую решения для локального копирования данных \ восстановления данных используя стандартные средства системы Linux(консольный cp, du и т.д.).

rsync -avP --size-only /media/HDD/Back/ /media/HDB/Back/

(обратите внимание: /media/HDD/Back/ со слешем на конце = «скопировать содержимое директории»)

--size-only заставит rsync сравнивать файлы только по размеру, поскольку POSIX ACL на ntfs-3g по умолчанию не работает.

Если ещё добавить параметр -n, rsync напишет, что собирается сделать, но не сделает этого (режим dry run).

AITap ★★★★★ ()
Последнее исправление: AITap (всего исправлений: 1)
Ответ на: комментарий от AITap

Правильно ли я понимаю, что если у меня будут файлы измененные таким образом, что не будет изменен их размер(число байт в файле останется неизменным), то мне нужно будет делать синхронизацию по контрольным суммам таким способом ?:

rsync -avPс /media/HDD/Back/ /media/HDB/Back/

Кроме того почитал параметры rsync'a, нашел параметр -r --recursive. в описании написано следующее: «Указывает rsync копировать каталоги рекурсивно. Без указания этого rsync совсем не будет копировать каталоги.». Обязательно ли мне использовать его, если внутри каталога Back есть и другие каталоги, или по-умолчанию считается, что будет копирование рекурсивно?

Еще есть вопрос по поводу проверки правильности синхронизации после выполнения rsync. Каким образом можно проверить правильность синхронизации или будет достаточно провести эмуляцию(если ничего не вывело, то все скопировано верно???):

rsync -navP --size /media/HDD/Back/ /media/HDB/Back/

kquick ()
Ответ на: комментарий от kquick

Вопрос с параметр -r снят(не заметил что -a автоматически включает -r)

kquick ()

P.S. Если будет полезно: до этого замечал такую вещь как изменение в выводе команды du до посещения каталога через Dolphin и после посещения(без изменения файлов и каталогов). Судя по всему он оставляет там какую-то информацию.

Скорее всего, создает или изменяет файл .directory

PreciousProtection ()
Ответ на: комментарий от kquick

rsync использует контрольные суммы автоматически (без параметров -c и --size-only), если видит, что атрибуты файлов (времена создания/модификации/доступа) изменились. Если заставить его использовать контрольные суммы для всех файлов, синхронизация займёт очень большое время.

rsync в какой-то степени сам проверяет себя по ходу работы, так что если он отрапортовал об успешном завершении, делать больше ничего не надо. rsync -navP можно использовать, чтобы посмотреть, чем на GNU/Linux различаются два дерева файлов.

AITap ★★★★★ ()

Похоже, что проблема как-то связана с Alternate Data Streams

Не совсем, но близко. В Linux принято считать место, занимаемое собственно директорией (имена файлов, их атрибуты, размеры и т.п.), а в Windows — нет. Размеры директорий не всегда напрямую связаны с числом файлов в них. Иногда они могут иметь разный размер, даже если в них одинаковые файлы. Я не знаю способа заставить du прекратить учитывать размер директорий, но сам в таком случае пользуюсь Midnight Commander. В нём можно запросить собственный формат в статусной строке. Если поставить size:12, размеры до терабайта будут показываться в байтах.

пакетов\документов

Что это за напасть с обратными слешами? Ты когда от руки пишешь, тоже обратные косые черты ставишь?

i-rinat ★★★★★ ()

Но мне ручное копирование и указанный выше алгоритм в принципе устраивает, в связи с чем я жду и приветствую решения для локального копирования данных \ восстановления данных используя стандартные средства системы Linux(консольный cp, du и т.д.). Но буду рад и услышать про надежные средства резервного копирования в Linux\Windows(как дополнительно).

man rsync уже советовали?

du до посещения каталога через Dolphin и после посещения(без изменения файлов и каталогов). Судя по всему он оставляет там какую-то информацию.

миниатюры картинок наверное. Потому-что всякую чушую оно хранит в своей отдельной базе AFAIK.

emulek ()
Ответ на: комментарий от i-rinat

В Linux принято считать место, занимаемое собственно директорией (имена файлов, их атрибуты, размеры и т.п.)

атрибуты, размеры и т.п.

ЩИТО?

Я не знаю способа заставить du прекратить учитывать размер директорий

ничего, что каталоги — тоже файлы?

emulek ()
Ответ на: комментарий от AITap

(обратите внимание: /media/HDD/Back/ со слешем на конце = «скопировать содержимое директории»)

Обрати внимание, что в /media/HDB/Back/ слеш в конце не нужен.

sdio ★★★★★ ()

Кроме rsync, в твоем случае можно использовать cp -u

  -u, --update
     copy  only  when  the  SOURCE file is newer than the destination
     file or when the destination file is missing
но rsync гибче, имеет больше возможностей.

sdio ★★★★★ ()

tar и md5sum, git для контроля файлов не устраивают?

DeadEye ★★★★★ ()
Ответ на: комментарий от DeadEye

tar, это слишком долго получится для 200 Gb данных. Там же не целиком другие данные, а только часть.

Решение с rsync вполне устраивает. Единственное хотелось бы еще способов для проверки действительно ли совпадают после синхронизации и размеры и количество файлов, каталогов либо суммы. du по понятным причинам не подходит. Либо пользоваться тем-же rsync с ключом -n(если ничего не вывело, то все в порядке и каталоги совпадают?). К предложенным выше решениям по rsync добавил еще ключ --delete. Как оказалось на втором бэкапе были каталоги\файлы аналогичные тем что в оригинале но с другими названиями. На windows не замечал этого(потому-что проверял через размер и количество), но после rsync'a получились дубликаты.

kquick ()
Ответ на: комментарий от kquick

можно сфорганить простенький скрипт который будет писать во временные файлы хешы копированных файлов а потом через wc их сравнивать, результат сразу на лицо.

CHIPOK ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.