?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Next Entry
dobro_backup.py
nyaload
_winnie
Выкладываю питоний скрипт для бэкапов, который доделал сегодня.

Бэкап за каждую дату - выглядит просто как папка. Для того, чтобы не хранить терабайт в каждой папке по много раз при создании нового бэкапа создаются хардлинки в предыдущий бэкап. Старые папки можно смело стирать.
Для того, чтобы быстро считать md5 от файлов - в директорию сохраняется файл с посчитаными md5 и timestamps/size. Если timestamp/size файла не изменился, то верим что md5 тоже не поменялся.
Скрипт работает под Linux и Windows (под Windows даже есть оптимизированый os.walk через FindFirstFile).
Возможно, можно разобрать на запчасти для быстрого копирования директорий в production.

Cам скрипт: dobro_backup.py

Дублирую сюда usage и todoшки-недоделки:

Usage: python "prog_name" destination_dir path1/source1 ... pathN/sourceN'

Copied result will be in the destination_dir/DATE_TIME/source1 ... destination_dir/DATE_TIME/sourceN'
Also there will be created files pathN/sourceN/hash_dir_info.txt (write access to source is needed now)'
When backup is complete, destination_dir/DATE_TIME/backup.complete is created, with timestamp info.
Hardlinks of duplicated files created to previous directory, to save space/time.
Deletion of old backup directories is safe.

Encryption and compression can be provided by the file-system (TrueCrypt + NTFS, for example).

Hardlinks to older-than-last backups are not created now (you may manually move/copy older files to last backup)


# known missing features and issues:
#
# todo: allow to create hardlinks to old backups, to handle changed source set
# ( ["music", "documents", "video"] -> ["music", "documents"] -> ["music", "documents", "video"] ).
# todo: needless rehashes of internal file hash_dir_info.txt
# todo: catch "source inside destination" errors and vice-versa
# todo: allow to rename sources targets
# todo: allow to store hash_dir_info.txt outside source directories
# todo: allow exclude dirs/mask
# todo: don't spam about known unreadable dirs ( Microsoft\Windows\WER\ReportQueue )



updated: похожие проекты:
https://github.com/candera/hobocopy/ , для Windows. Поддерживает Volume Shadow Copy. Но его инкрементальному бэкапу я бы файлы не доверил, он работает как "скопировать файлы, таймстемпы которых старше последней даты бэкапа". Что может фейлится кучей разных способов, и можно считать что не работает для больших коллекций файлов.
Никакой дедубликации в приёмнике, просто копирование. Ключевое отличие от остального - использование Shadow Volume для заблокированых файлов, соответственно можно бэкапить Outlook (но не Thunderbird).


https://code.google.com/p/boar/ - простая система контроля версий бинарных файлов. Репозиторий - можно считать, что промежуточные снэпшоты оттуда удалять нельзя, и имеет непрозрачный формат (хрен вытащишь свою коллекцию mp3-шек без клиента boar).

Моё основное отличие от других систем - это то, что destination-репозиторий выглядит просто как директория с файлами. Фундаментальный недостаток - для каждого файла создаётся по линку, и скорость бэкапа завязано на это. Нулевой бэкап в новый чистое место - работает быстрее board на десятки процентов.


  • 1
Скрипт не смотрел, но -осуждаю- интересуюсь: как дела с теневым копированием? Чтобы можно было делать бэкап из-под открытого ворда, например.

Если бы можно было примонтировать shadow volume как обычную папку - добавил, но это не папка, а COM-интерфейсы (причем очень запутанные, а не "дай файл"), так что увы :(

Можно делать бэкапы, когда слушаешь музыку и смотришь фильмы! И быть уверенным, что файлы и хеши файлов не уйдут кому-то "для анализа" или по "законному запросу от спецслужб"

Edited at 2014-06-02 07:36 am (UTC)

Не понял, откуда эти параноидальные мысли про анализ и запросы.
Думаешь, служба теневого диска этим занимается? или, что сторонние бэкапилки этим занимаются?

Я сам с VSS не упражнялся, но вот здесь http://gotch.techfaq.ru/archives/59 пишут, что есть более-менее приемлемый интерфейс командной строки.

Вот тут копия поста, но форматирование (и слеши в снипетах кода) не убито - http://i-alex-s.blogspot.ru/2011/06/windows-2.html

Хм, тогда есть шанс, что мне (или кому-то ещё) надоест выключать браузер перед бэкапом, и я попробую взять файлы из VSS.
vshadow.exe по умолчанию не установлен, т.е. он довольно бесполезен для использования из скриптов на github для других людей

Win7 Professional есть vssadmin:
http://technet.microsoft.com/en-us/library/cc754968.aspx
http://blogs.msdn.com/b/adioltean/archive/2004/12/14/301868.aspx

В Win8 и WinXP есть какие-то ограничения на persistent shadow volumes, а в пример с vssadmin используется именно эта штука ( http://superuser.com/questions/336148/programmatically-create-a-shadow-copy-on-win-xp )
vssadmin разговаривает со мной на русском языке - простор для граблей при попытке парсить вывод.
Вообщем, пока нихрена не понятно, какой конкретно код писать, и в нём может быть два-три варианта для WinXP/Vista/Win7/Win8. Даже command-line тулзы далеки от от "просто примонтируй" - нужно писать обвязку и тестировать под разными версиями windows.

> Думаешь, служба теневого диска этим занимается?
Не то, чтобы она занимается, но история файлов оттуда полезна для экспертов, исследующих компьютер ( https://www.magnetforensics.com/volume-shadow-copy-forensics/ )


> или, что сторонние бэкапилки этим занимаются?
Я думаю, что бэкапилки в "облако" - запросто занимаются. Или под благородными намерениями "давайте соберём статистику о пользователях ради улучшения интерфейса", гораздо менее благородными "давайте продадим статстику", или совсем-совсем благородными "давайте пошлём в полицию хеши MP3-шек, вдруг они пиратские"


Edited at 2014-06-02 07:41 pm (UTC)

Есть ещё подозрение, что файлы приложений, которые заблокированы не VSS-aware приложениями - всё равно будут в так называемом crash-consistent state (для бинарных баз данных SQLite - можно считать что с некоторой вероятностью разрушены )

http://msdn.microsoft.com/en-us/library/windows/desktop/aa381500%28v=vs.85%29.aspx

Almost every system will have some [...] that are VSS unaware, so it is always likely that some of the data on a shadow copy will need to be thought of as being in a crash consistent state.
As with preparations for conventional backups, if possible, backup operators should attempt to suspend or terminate such applications prior to starting a VSS backup job.

Поэтому не факт, что для браузеров или почтовых приложений или прочих sqlite based приложений - есть какой-то смысл использовать VSS. Всё равно надо выключать браузер перед бэкапом его файлов.

Вот что я нашёл: https://github.com/candera/hobocopy/ ( не запускал, не знаю как будет работать инкрементальный бэкап для огромной коллекции файлов ).

Как быть с лимитом хардлинков?

Даже не обрабатывая специально случай достижения лимитов - хватит. На NTFS 1023 хардлинка на один файл. В ext4 - 65000. История бекапов больше 1000 штук, имхо, никому не интересна.

FindFirstFile довольно тормозное API. Путь джедая - это NtQueryDirectoryFile.

Судя по описанию, каталоги с одинаковыми именами в бакапе окажутся слиты в один.

Ну и на всякий случай: как и во многих других способах, неиспользование сжатия/шифрования/другой защиты ведет к риску потери данных. Плюс к этому в данном конкретном методе есть опасность потери из-за искажения данных - испортил один файл - конец всей версии.

Каталог - нет. Во-первых, это еще немножко кода и багов, и это отдельная сущность ( junctions points, reparse points )
Во-вторых, есть риск, что какой-нибудь незатейливый код рекурсивного удаления - зайдет в расшаренную между бэкапами ветку и наломает там дров. Именно то, что ты описал про "испортил один файл".
По поводу "испортил один файл" я кажется знаю, что надо делать, сделать все файлы read-only, тогда меньше вероятность случайно изменить файл.


Про "испортил один файл" - это я про шифрующие трояны/вирусы.
Их обычное поведение - сканирование всего, что подмонтировано, на всякие картинки, документы, архивы и шифрование небольшого куска файла, обычно начального.

Когда файловая система постоянно подмонтирована, если такой хватануть, то накроется весь бакап вместе с источником.

Не знаю, как такое побороть простым образом, и чтобы было удобно пользователю (чтобы было удобно взять и стереть старую папку, но вирус не мог её зашифровать).

Я на всякий случай делаю бэкап на два разных диска, и храню один из них вне квартиры (во избежание потери от пожара/воров/потопа/детей/таких вирусов/..).

Про readonly - это хорошая мысль.
Винни, а ты смотрел boar?

Посмотрел. Хорошая программа, с похожими целями, с кучей фичей, которых нет у меня.
Что у неё проще - меньше требований к файловой системе репозитория (я требую возможности делать hardlink).

Ещё что у неё ещё хорошо - мне при создании нового снепшота с 20000 файлами нужно создать 20000 хардлинков. Это конечно не скопировать всё целиком, но требует десятка секунд. А boar - только запишет список новых файлов.

Теперь, что у меня лучше:

У boar внутри - безымянные блобы, а соответствие имя файла -> блоб раскидано по отдельным json-файлам, т.е. даже программисту будет нелегко извлечь сотню файлов "как было раньше" без оригинального софта. Впрочем, безымянные блобы за счет непрозрачного репозитория позволяют надобавлять кучу фичей (например, хранить в будущем бинарные диффы файлов, а не файлы целиком), избежать кучи граблей (например, проблем с хитрыми именами файлов), и позволяют не пытать файловую систему огромным числом хардлинков.
У меня проще формат "репозитория" - обычная папка с файлами, которые можно стирать, и в которых легко ориентироваться привычными файл-менеджерами. Прийти с диском к другу, и скопировать ему нужную папку. Можно смело стирать внутри бэкапа файлы, это не является нарушением целостности "репозитория".

Более того, если на диске есть старый бэкап, сделаный методом "скопировать файлы" или блобы того же boar - то мой скрипт сможет их подцепить хардлинками (если добавить файлик backup.complete с нулевым тайстемпом). Собственно, я потратил два дня на скрипт, чтобы сэкономить 3 часа первоначального копирования терабайта в существующий старый бэкап :)

У меня проще команды:
boar:
boar mkrepo /home/joe/boar_repo
boar --repo=/home/joe/boar_repo mksession MyPictures
boar --repo=/home/joe/boar_repo import pictures MyPictures

мой скрипт:
mkdir /home/joe/boar_repo
dobro_backup.py /home/joe/boar_repo pictures

У меня проще исходник, если вдруг надо всё переделать под себя: 8 килобайт против 150 килобайт (плюс ещё 100 килобайтов тестов).

Техническая особенность - я копирую файл сразу после посчета его md5, поэтому файл ещё в системном кеше, а boar считывает данные по два раза, есл их больше, чем влезает в оперативную память.

Взял старую папку с документами (4гб, 16'000 файлов, на компьютере установлено 32гб ram, Windows7, python2.7, с одного HardDrive на другой SSD), несколько раз (чтобы не мерять эффекты файл-кеша) забэкапил обоими программами с нуля. У меня работает чуть быстрее, 50 секунд вместо 70.
На объёмах, которые не влезают в RAM - не мерял, это нужно несколько часов для многократного тестирования.
Повторные бэкапы той же папки без измений - у boar 3 секунды, у меня 5 секунд (я выигрываю на сильно более быстром обходе файловой системы, и проигрываю на том, что создаю 16'000 хардлинков в точке приёма).

Итого: Если хочется простоты, и "прозрачного" репозитория где файлы - это просто файлы в папках, то у меня сильное преимущество. Если хочется надёжности и возможности не приглядывать каждый раз за прогрессом бэкапа из-за кривых имен файлов - лучше использовать boar (при этом не получится посмотреть фотки прямо в бэкапе, нужно экспортить обратно). По скорости примерно одинаково. У boar гораздо больше фичей, например есть уже готовый бэкап по ssh, и всякие фишки системы контроля версий.

  • 1