Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 143
Действительно шустрый алгоритм, но php-ориентация смущает. Забыли указать на каком этапе разработка.
Ну сам формат будет открытый, так что при желании можно будет сделать реализацию на других языках. К тому же он использует вполне стандартные модули zlib и mcrypt. Основная фишка именно в специализированности контейнера, под бэкап файлов и БД. PHP используется потому, что это мой основной язык, да и на сайтах он по прежнему один из самых популярный, не зря в коробке на в начале страницы логотипы популярных CMS.
Что касается этапа, сейчас идет отработка технологии, тестируются отдельные части на максимальную эффективность. Так как помимо самого контейнера, еще ведется работа над препроцессингом, файлы будут сортироваться по типам, а также сжимаемые/несжимаемые, определяются оптимальные размеры блоков.
Что касается этапа, сейчас идет отработка технологии, тестируются отдельные части на максимальную эффективность. Так как помимо самого контейнера, еще ведется работа над препроцессингом, файлы будут сортироваться по типам, а также сжимаемые/несжимаемые, определяются оптимальные размеры блоков.
Думаю имеет смысл рассмотреть и rdiff-backup — инкрементальный, последняя версия всегда доступна напрямую, возможность легко восстановить/удалить файлы за любой промежуток времени, удалённый бэкап, работа с бинарными данными, хэши. И не велосипед.
А rdiff-backup разве складирует файлы в один файл? Да и я всё же ориентируюсь немного на другую часть пользователей, те кто не сильно дружит с консолью. Причем тулза из коробки будет дружить с облачными хранилищами (Dropbox, Google Drive, Яндекс Диск, и другие). Как по мне удобнее на сервере сгрузить всё в контейнер, а потом раскидать копии этого большого файла по разным хранилищам, чем возиться с кучей мелких файлов.
В один файл не складирует, насколько я помню. Это позволяет уменьшить время создания бэкапа и объём передаваемой информации. Плюс не нужно создавать и хранить (хотя бы и временно) файл бэкапа на бэкапируемой системе. С другой стороны, это затрудняет использовать Ваш кейс по раскидыванию бэкапов по кучи мест.
Кстати, я бы поручил «дружбу» с хранилищами утилитке backupninja — для неё можно настроить свои обработчики бэкапа, а всю черновую работу — запуск по крону, оповещение по мылу она возьмёт на себя. Но это консоль, что тоже не подходит под Ваши требования :)
Кстати, я бы поручил «дружбу» с хранилищами утилитке backupninja — для неё можно настроить свои обработчики бэкапа, а всю черновую работу — запуск по крону, оповещение по мылу она возьмёт на себя. Но это консоль, что тоже не подходит под Ваши требования :)
В один файл всё складируется только когда делается первый Полный бэкап, в дальнейшем заливаются измененные блоки, но они также пакуются в один контейнер. Т.е. если с предыдущего бэкапа изменилось 5 файлов, то эти 5 файлов пакуются в один контейнер и заливаются в хранилище, а не по очереди заливаются 5 файлов. Так что с точки зрения экономии трафика, будет еще лучше.
Да я как бы не против консольщиков. Но мне не очень нравится unix-way, когда программа делает, какую-то одну свою задачу, и не подозревает о существовании других, плюс для того, чтобы заставить её работать нужно перелопатить кучу конфигов, и гуглить готовые конфиги. Мне по душе GUI, и чтобы для бэкапа сайта нужно было просто залить софтинку, зайти туда браузером (даже со смартфона), выбрать в удобном виде что бэкапить, и куда. А для заливки на Dropbox или Google Drive, нужно было бы просто выбрать его из меню и пройти в том же браузере OAuth авторизацию.
Да я как бы не против консольщиков. Но мне не очень нравится unix-way, когда программа делает, какую-то одну свою задачу, и не подозревает о существовании других, плюс для того, чтобы заставить её работать нужно перелопатить кучу конфигов, и гуглить готовые конфиги. Мне по душе GUI, и чтобы для бэкапа сайта нужно было просто залить софтинку, зайти туда браузером (даже со смартфона), выбрать в удобном виде что бэкапить, и куда. А для заливки на Dropbox или Google Drive, нужно было бы просто выбрать его из меню и пройти в том же браузере OAuth авторизацию.
У меня тут есть один велосипед…
github.com/KOLANICH/PHP-Backuper
github.com/KOLANICH/PHP-Backuper
Ну, доколе просили :)
Ах да, сайт на фреймворке Laravel :)
dirs 1494
files 10247
full_size 71.502
dup_size 2.506
archive_size 40.338
duplicates 692
bigfiles 249
bf_blocks 1581
bf_dup 45
bf_size 45.058
bf_dup_size 1.221
time 162.6651
Ах да, сайт на фреймворке Laravel :)
Прочёл с интересом, за что спасибо автору! Но бэкапы буду делать по старинке ;)
В TAR отсутствует каталог с содержимым архива. Поэтому для просмотра содержимого архива нужно сканировать архив, пройдясь по всем заголовкам файлов. Что на больших архивах может занимать значительное время.
Жесть. Я-то думал что хотябы в самом несжатом TAR оно есть. Теперь уж совсем непонятно как люди это терпят. Сам всегда (когда есть возможность) жму в 7z (там есть и solid сжатие и нормальное оглавление и почти всё, что душе угодно) или (в случае когда надо дать другим) — в zip.
gem backup (-:
Здесь вопрос не в том, что это велосипед, а в том, что непонятно, зачем это вообще делать — в том смысле, что зачем вообще бэкапить файлы сайта вместе с его БД, да еще и в пропьетарный формат.
Хм, а зачем вам файлы сайта без БД? Обычно для сайта болезненна потеря и того, и другого.
Зачем бэкапить базу именно в таком виде как я описал? Это быстрее (позволяет заливать данные в MySQL с помощью SELECT INTO OUTFILE/LOAD DATA, что в несколько раз быстрее, чем классические SELECT/INSERT-запросы), это более функционально.
К примеру, что вы будете делать если вам нужно восстановить одну таблицу из классического бэкапа (tar или zip, в которых среди файлов есть dump.sql с запросами внутри).
Придется сначала распаковать из архива дамп (хорошо еще если точно помните его название и расположение. Потом нужно будет как-то выковырять из самого дампа именно таблицу (скорее всего это вручную в редакторе будет делаться), потом выполнить этот SQL на сервере.
В моем же случае вам просто нужно зайти в тулзу и выбрать какую таблицу из БД нужно восстановить. Остальное делается автоматом, так как в каталоге архива содержится информация о том, в каком месте файла находится нужная вам таблица.
Зачем бэкапить базу именно в таком виде как я описал? Это быстрее (позволяет заливать данные в MySQL с помощью SELECT INTO OUTFILE/LOAD DATA, что в несколько раз быстрее, чем классические SELECT/INSERT-запросы), это более функционально.
К примеру, что вы будете делать если вам нужно восстановить одну таблицу из классического бэкапа (tar или zip, в которых среди файлов есть dump.sql с запросами внутри).
Придется сначала распаковать из архива дамп (хорошо еще если точно помните его название и расположение. Потом нужно будет как-то выковырять из самого дампа именно таблицу (скорее всего это вручную в редакторе будет делаться), потом выполнить этот SQL на сервере.
В моем же случае вам просто нужно зайти в тулзу и выбрать какую таблицу из БД нужно восстановить. Остальное делается автоматом, так как в каталоге архива содержится информация о том, в каком месте файла находится нужная вам таблица.
Хм, а зачем вам файлы сайта без БД? Обычно для сайта болезненна потеря и того, и другого.
Нет, правильный вопрос — зачем мне вообще бэкап файлов сайта, когда есть версионник, в котором лежат исходники.
К примеру, что вы будете делать если вам нужно восстановить одну таблицу из классического бэкапа
Подниму рядом бэкап базы целиком, затем скопирую нужные данные (если мне нужно восстанавливать только данные). Но обычно так не делают, просто поднимают БД целиком поверх, чтобы сохранить целостность.
В моем же случае вам просто нужно зайти в тулзу и выбрать какую таблицу из БД нужно восстановить. Остальное делается автоматом, так как в каталоге архива содержится информация о том, в каком месте файла находится нужная вам таблица.
… и я полностью в зависимости от вашей тулзы и вашей поддержки. Очень смешно, да.
зачем мне вообще бэкап файлов сайта, когда есть версионник, в котором лежат исходники.
А пользовательские данные у вас тоже в версионнике? Вон на том же сайте №1, из 934 МБ, файлов самого Vbulletin там ну мегабайт 10 от силы, остальное пользовательские данные.
Но обычно так не делают, просто поднимают БД целиком поверх, чтобы сохранить целостность
Целостность никуда не денется, если к примеру изменили текст какой-то статьи (неудачно). Видимо вы мало общались с блондинками заполняющими корпоративные сайты, они вам поднимут бэкап базы :)
К тому же ничего не мешает восстанавливать все связанные таблицы, но при этом не трогать не связанные, к примеру таблицу сессий, чтобы у пользователей авторизация не послетала.
В общем не делают так банально из-за трудоёмкости, а совсем не из-за целостности.
Кстати в моем варианте потенциально возможно даже восстанавливать отдельные строки или ячейки, так как из-за простого формата с разделителями табами, значительно упрощается и ускоряется парсинг данных, разбиение их на строки и ячейки.
я полностью в зависимости от вашей тулзы и вашей поддержки
Никто не запрещает использовать несколько утилит для бэкапа. Да я согласен, что у нового формата есть недостаток в малой распространенности, но делать очередную обертку поверх zip или tar, как-то не очень интересно.
А пользовательские данные у вас тоже в версионнике?
Пользовательские данные у меня в БД.
Целостность никуда не денется, если к примеру изменили текст какой-то статьи (неудачно). Видимо вы мало общались с блондинками заполняющими корпоративные сайты, они вам поднимут бэкап базы :)
Бэкап базы должен поднимать администратор.
А проблема «неудачно изменили текст какой-то статьи» решается не бэкапом, а хранением версий. Не надо путать эти два понятия.
К тому же ничего не мешает восстанавливать все связанные таблицы, но при этом не трогать не связанные, к примеру таблицу сессий, чтобы у пользователей авторизация не послетала.
Не надо хранить рантайм-данные (навроде таблицы сессий) в той же БД, что и персистентные данные (навроде текста статей).
из-за простого формата с разделителями табами
Вам никогда данные с табами не попадались? Ну так рад за вас.
Пользовательские данные у меня в БД.
Т.е. всякие там файлы, фотки, аватарки юзеры не заливают?
Бэкап базы должен поднимать администратор.
Я уже как бы много лет занимаюсь утилиткой для бэкапа базы. Администратор должен быть ещё и квалифицированный :) Но это в идеальном мире, а в реальном мире, поднимать бэкап должна иметь возможность любая блондинка, которая открыла свой бложик в wordpress за 5 минут.
а хранением версий
Если таковая есть на сайте, что далеко факт.
Не надо хранить рантайм-данные
Ну то для примера, ладно еще пример, навернулась таблица со статьями, но с момента последнего бэкапа были добавлены штук 5 новостей в таблицу новостей. Будете поднимать старый дамп попутно затирая добавленные новости?
Вам никогда данные с табами не попадались?
Я знаю магическое слово «экранирование», в итоге табы будут только в разделителях. В то время как в случае с SQL файлом вам уже придется нехилый парсер подключать, так как ячейки разделены запятыми, которые в любых количествах могут быть в тексте, плюс нужно учитывать кавычки, и то что эти кавычки могут быть экранированными.
Т.е. всякие там файлы, фотки, аватарки юзеры не заливают?
А как обстоит дело с удаленным размещением файлов, фоток, аватарок? Или у вас не встречалось ситуации с несколькими фрондами для исполнения кода сайта?
Т.е. всякие там файлы, фотки, аватарки юзеры не заливают?
А что, их в БД хранить никак не возможно?
Но в реальном мире, поднимать бэкап должна иметь возможность любая блондинка, которая открыла свой бложик в wordpress за 5 минут.
Зачем?
Если таковая есть на сайте, что далеко факт.
А должна быть. Не надо решать одну задачу инструментом от другой.
Ну то для примера, ладно еще пример, навернулась таблица со статьями, но с момента последнего бэкапа были добавлены штук 5 новостей в таблицу новостей. Будете поднимать старый дамп попутно затирая добавленные новости?
Да, потому что эти новости могли ссылаться на статьи, которые мы сейчас перезатрем.
В то время как в случае с SQL файлом вам уже придется нехилый парсер подключать, так как ячейки разделены запятыми, которые в любых количествах могут быть в тексте, плюс нужно учитывать кавычки, и то что эти кавычки могут быть экранированными.
Г-ди, а зачем SQL-файл-то для этого использовать? Мало, что ли, машиночитаемых форматов представления данных?
А что, их в БД хранить никак не возможно?
Ну обычно не принято, но и не запрещено.
Зачем?
Что зачем? Зачем блондинке блог, или зачем ей возможность восстановить свой блог из бэкапа? Скажем так чтобы меньше админов доставала.
А должна быть. Не надо решать одну задачу инструментом от другой.
Ну как бы мир далеко не идеален :)
Да, потому что эти новости могли ссылаться на статьи, которые мы сейчас перезатрем.
И что с того, если новости ссылались на статьи которые уже были в бэкапе? Ну тут уже дело ваше, я же просто восстановлю таблицу со статьями, и новости останутся на месте.
Г-ди, а зачем SQL-файл-то для этого использовать?
А, дамп базы вы в каком виде храните? Не в SQL-файле?
Ну обычно не принято,
Кем не принято?
Что зачем? Зачем блондинке блог, или зачем ей возможность восстановить свой блог из бэкапа?
Зачем ей такая возможность? А уж тем более — с настройками? Блондинке нужна кнопочка «верните как было», причем в интерфейсе того же блога. И все.
И что с того, если новости ссылались на статьи которые уже были в бэкапе?
А если не было? Потому что добавили эти новости одновременно со статьями?
Ну тут уже дело ваше, я же просто восстановлю таблицу со статьями, и новости останутся на месте.
Я тоже могу так сделать, просто не вижу смысла и целесообразности.
А, дамп базы вы в каком виде храните? Не в SQL-файле?
Нет, конечно. Есть же нормальные бэкапы, бинарные со всеми плюшками и поэтессами.
Ладно завязываю этот бесполезный спор мы о разных вещах говорим.
Кем не принято?
фейсбуком как минимум :)
А если серьёзно, то гораздо проще работать с дампами весом в 100 метров, чем в 10 гиг (а с учётом хранения файлов в базе такие размеры имеют место быть).
Да и потом для обычного просмотра фоток каждый раз делать запрос к базе, не жирно ли?
фейсбуком как минимум
А у Fb РСУБД?
А если серьёзно, то гораздо проще работать с дампами весом в 100 метров, чем в 10 гиг (а с учётом хранения файлов в базе такие размеры имеют место быть).
Ну так частичные бэкапы никто не отменял (а дамп без файлов — это все равно частичный бэкап).
Да и потом для обычного просмотра фоток каждый раз делать запрос к базе, не жирно ли?
Нет, при правильной организации — не жирно. Или у вас путь к файлу святым духом отдается?
А у Fb РСУБД?
я к тому, что если бы фейс хранил все файлы пользователей в базе, это был бы действительно ночной кошмар администраторов…
Нет, при правильной организации — не жирно. Или у вас путь к файлу святым духом отдается?
Чтобы определить путь к файлу не обязательно делать запросы к базе вообще, его можно определить по заведомо определённым правилам. Как раз при правильной их организации в файловой системе.
В вашем же случае необходимо:
1. Делать лишний запрос к базе, который кстати сказать не такой уж и лёгкий, т.к. ему необходимо отдать всё тело файла. (При частом открытии одной сильно наполненной фотками странички, ddos на базу гарантирован. А в случае хранения файлов в файловой системе nginx кеширует и отдаёт файлы практически моментально и ничего более не требуется)
2. Хранить лишнюю таблицу с именами файлов и их содержимым, которая со временем будет только разрастаться.
я к тому, что если бы фейс хранил все файлы пользователей в базе, это был бы действительно ночной кошмар администраторов…
Fb — это типичный special case, со специфичной нагрузкой.
Делать лишний запрос к базе, который кстати сказать не такой уж и лёгкий, т.к. ему необходимо отдать всё тело файла. (При частом открытии одной сильно наполненной фотками странички, ddos на базу гарантирован. А в случае хранения файлов в файловой системе nginx кеширует и отдаёт файлы практически моментально и ничего более не требуется)
Файлы в БД хранятся тогда, когда есть нормальный апп-сервер. На котором никто не мешает сделать кэш. Плюс еще есть смешные режимы, когда файл хранится в БД, но при этом снаружи это выглядит как SMB-шара.
В общем, это вечный спор. На одной стороне — целостность и удобство администрирования, на другой — быстродействие и прямолинейность разработки. Как всегда.
Файлы в БД хранятся тогда, когда есть нормальный апп-сервер. На котором никто не мешает сделать кэш.
вот скажите пожалуйста зачем делать кэш когда файлы итак есть?
В общем, это вечный спор. На одной стороне — целостность и удобство администрирования, на другой — быстродействие и прямолинейность разработки. Как всегда.
я всегда наивно полагал, что быстродействие является самым важным фактором при разработке сайтов, как ни крути сайты делаются для пользователей, а не для администраторов
Как всегда.
действительно, не убедили )
вот скажите пожалуйста зачем делать кэш когда файлы итак есть?
А зачем nginx его делает? Или вы думаете, что Fb без кэшей работает?
я всегда наивно полагал, что быстродействие является самым важным фактором при разработке сайтов
Нет. Быстродействие — всего лишь один из критериев оценки решения.
Вы вот какой онлайн-банкинг предпочтете, быстрый или безопасный?
как ни крути сайты делаются для пользователей, а не для администраторов
Какой пользователю толк от (пусть даже самого быстрого) сайта, который не могут ни развивать (потому что нам тонна неподдерживаемого кода), ни нормально поднять после аварии (потому что он не бэкапится)?
А у Fb РСУБД?
у фэйсбука MySQL
dirs 53045
files 132904
full_size 6002.819
dup_size 2361.505
archive_size 2716.012
duplicates 114952
bigfiles 44403
bf_blocks 179124
bf_dup 73918
bf_size 4766.643
bf_dup_size 1866.851
time 1725.34368
dirs 2912
files 14214
full_size 203.521
dup_size 10.226
archive_size 124.562
duplicates 4204
bigfiles 880
bf_blocks 5259
bf_dup 247
bf_size 148.411
bf_dup_size 6.484
time 68.00453
Когда будет DEB пакет или лучше даже исходники для компиляции под Линукс и винду.
Я сейчас остановился на ZIP, так как есть поддержка что в Линуксе что в винде, неплохой уровень сжатия, простота использования.
Шифрованием редко пользуюсь, в данный момент использую шифрованные диски для важной инфы, поэтому дополнительно шифровать нет смсла
Я сейчас остановился на ZIP, так как есть поддержка что в Линуксе что в винде, неплохой уровень сжатия, простота использования.
Шифрованием редко пользуюсь, в данный момент использую шифрованные диски для важной инфы, поэтому дополнительно шифровать нет смсла
dirs 241
files 911
full_size 7.222
dup_size 0.128
archive_size 9.422
duplicates 97
bigfiles 32
bf_blocks 87
bf_dup 0
bf_size 1.979
bf_dup_size 0
time 0.68338
По делу — а заложена ли в дизайн этой системы возможность использования произвольного алгоритма для сжатия блоков данных? Скажем, я бы хотел использовать 7z ppmd, уж больно хорошо он жмет текстовые данные.
Офтопик — А откуда взята фотография велика для статьи? На их офсайте не нашел такой модели. Вроде, не фотошоп, или?
Офтопик — А откуда взята фотография велика для статьи? На их офсайте не нашел такой модели. Вроде, не фотошоп, или?
Да у блоков будет информация сжат ли он, и если сжат то каким методом (хотя пока только с Deflate экспериментирую).
Что касается велика, просто зашел в Google картинки, чтобы нагуглить фотку необычного велика, понравился именно этот. Картинку нашел здесь, насколько понимаю там комплекты продаются, для преобразования любого велика.
Что касается велика, просто зашел в Google картинки, чтобы нагуглить фотку необычного велика, понравился именно этот. Картинку нашел здесь, насколько понимаю там комплекты продаются, для преобразования любого велика.
Я пользуюсь git'ом и проблема бэкапа файлов сайта передо мной не стоит.
БД и картинки-видяшки-прочие-файлы тоже целиком держите в репозитории?
Им dedup не поможет…
Сжатие тоже в принципе.
Сжатие тоже в принципе.
В том то и дело, что стоит задача бекапа не файлов сайта, а контента (файлы контента) и бд. Мы же технари, давай общаться с использованием соответствующей терминологии.
Автор поста явно пишет: «Сейчас работаю над новым PHP-скриптом, который будет бэкапить не только базу данных, но и файлы сайта» (выделение мое).
Да, да, мне стоит поправиться, ибо не корректно выразил свою мысль. В реалиях обычно не стоит задача бекапа кода сайта :)
Что-то я не понимаю, под файлами сайта имеются ввиду все файлы которые находятся на сайте. С чего вы взяли, что речь только о файлах CMS?
Кстати была идея, еще что-то типа антивира сделать, чтобы в случае изменения файлов могла извещать.
Кстати была идея, еще что-то типа антивира сделать, чтобы в случае изменения файлов могла извещать.
А я нигде и не говорил, что речь идет только о файлах CMS.
Другое дело, что пользовательские данные не должны находиться на сайте, но это уже грех вашей архитектуры.
Другое дело, что пользовательские данные не должны находиться на сайте, но это уже грех вашей архитектуры.
Вы хотите сказать, что нет сайтов на которых пользовательские данные находятся не на отдельных серверах? :)
Тут вообще в первую речь о массовом решении, так сказать для домохозяек. Так как понятное дело, что у людей у которых под пользовательские данные отдельные сервера, уже и так давно настроен софт для бэкапа, и что они не будут пробовать что-то новое, только что появившееся.
Тут вообще в первую речь о массовом решении, так сказать для домохозяек. Так как понятное дело, что у людей у которых под пользовательские данные отдельные сервера, уже и так давно настроен софт для бэкапа, и что они не будут пробовать что-то новое, только что появившееся.
Вы хотите сказать, что нет сайтов на которых пользовательские данные находятся не на отдельных серверах?
Я хочу сказать, что пользовательские данные должны быть полностью отделены от исполняемого кода. Не важно, на одном это сервере, или на нескольких.
Тут вообще в первую речь о массовом решении, так сказать для домохозяек.
Как я уже говорил, в массовом решении «для домохозяек» должна быть одна кнопка «верните как было», и все ваши навороты с индексами, потоками, дедупами и так далее их не волнуют.
Я хочу сказать, что пользовательские данные должны быть полностью отделены от исполняемого кода
И какое отношение это имеет к бэкапу?
и так далее их не волнуют.
Не спорю, их так же не волнуют внутренности айфонов, но так, что теперь не обсуждать на специализированном сайте их внутренности и как писать программы для домохозяек для айфона?
И какое отношение это имеет к бэкапу?
Прямое. Одно бэкапить надо, другое нет.
Не спорю, их так же не волнуют внутренности айфонов, но так, что теперь не обсуждать на специализированном сайте их внутренности и как писать программы для домохозяек для айфона?
В данном случае это банальная излишняя функциональность.
Так какие проблемы выбрали какие каталоги бэкапить, какие-то нет, да и всё. В любом случае это будут файлы, а назначение этих файлов бэкаперу уже как-то фиолетово.
Чего это излишне наоборот, инкрементальные бэкапы и дедупликация для домохозяки значит «бэкап любимого гламурного бложика будет меньше места занимать», а вот детали технологий ей уже пофиг. Возьмите тот же Time Machine, там тоже есть и инкрементальный бэкап, и версионирование, насчет дедупликации не знаю, но не важно, и спойно их используют домохозяйки, потому что для этих страшных названий есть простой и удобный GUI.
Чего это излишне наоборот, инкрементальные бэкапы и дедупликация для домохозяки значит «бэкап любимого гламурного бложика будет меньше места занимать», а вот детали технологий ей уже пофиг. Возьмите тот же Time Machine, там тоже есть и инкрементальный бэкап, и версионирование, насчет дедупликации не знаю, но не важно, и спойно их используют домохозяйки, потому что для этих страшных названий есть простой и удобный GUI.
Так какие проблемы выбрали какие каталоги бэкапить, какие-то нет, да и всё.
Лишнее место для ошибки, особенно при восстановлении.
Чего это излишне наоборот, инкрементальные бэкапы и дедупликация для домохозяки значит «бэкап любимого гламурного бложика будет меньше места занимать», а вот детали технологий ей уже пофиг.
В любимом гламурном бложике дедупликация вообще никого не волнует, потому что там не бывает дублей, а инкрементальные бэкапы означают, что продолбал один — продолбал все.
Когда вы говорите о домохозяйках — эта функциональность должна быть встроена прямо в платформу, которой она пользуется. И бэкап, как средство восстановления после сбоев, ей тоже не нужен, потому что она никогда не будет сама восстанавливать свой бложик, за это отвечает хостер. Ей нужна простая и понятная система версионирования и отката ее собственных изменений, вот и всё.
Дедупликация тесно связана с инкрементальным бэкапом. И позволяет не бэкапить постоянно один и тот же кусок таблицы с постами, к примеру.
Насчет продолбал бэкап, не понял о чем речь.
Давайте не будем рассуждать что и куда должно быть встроено, а посмотрите на реальный мир, что встроено в wordpress, joomla, drupal, и т.п. в лучшем случае корявейшая бэкапилка базы.
Про отвечающего хостера, это в ту же степь про идеальный мир ;)
Насчет продолбал бэкап, не понял о чем речь.
Давайте не будем рассуждать что и куда должно быть встроено, а посмотрите на реальный мир, что встроено в wordpress, joomla, drupal, и т.п. в лучшем случае корявейшая бэкапилка базы.
Про отвечающего хостера, это в ту же степь про идеальный мир ;)
Насчет продолбал бэкап, не понял о чем речь.
А вы не в курсе того, что продолб одного инкрементального бэкапа из цепочки приводит к невалидности всего в этой цепочке после него?
Давайте не будем рассуждать что и куда должно быть встроено, а посмотрите на реальный мир, что встроено в wordpress, joomla, drupal, и т.п. в лучшем случае корявейшая бэкапилка базы.
Повторяю еще раз: должно быть встроено. Сделайте свое решение, которое будет встроено в WP, джумлу, друпал и так далее — будет вам профит. А сторонняя утилита, извините, домохозяйке, да еще и разворачивающей свой бложик на wordpress.com (а вы думаете, она свой сервер поднимать будет? а нафига?) — не подмога.
Про отвечающего хостера, это в ту же степь про идеальный мир
Платите деньги, получайте SLA. И всё.
С таким же успехом можно и весь бэкап продолбать. Для надежности тулза позволяет заливать бэкап в несколько разных мест. Да и ни что не мешает настроить стратегию бэкапа так, чтобы к примеру раз в неделю делался полный бэкап.
Так так и задумано, оно будет встраиваться, но помимо этого, будет работать и отдельно. Так как при навернувшейся базе в админку WP, Joomla и т.п. будет сложно попасть.
Речь как бы не обо мне, а пользователи разные бывают, не нужно всех судить по себе. Тут люди зачастую не знают, что значит в бинарном режиме файл залить на сайт…
Сделайте свое решение, которое будет встроено в WP, джумлу, друпал и так далее
Так так и задумано, оно будет встраиваться, но помимо этого, будет работать и отдельно. Так как при навернувшейся базе в админку WP, Joomla и т.п. будет сложно попасть.
Платите деньги, получайте SLA. И всё.
Речь как бы не обо мне, а пользователи разные бывают, не нужно всех судить по себе. Тут люди зачастую не знают, что значит в бинарном режиме файл залить на сайт…
И что, по вашему мнению, должен сделать пользователь класса «домохозяйка», не имеющий доступа к физическому хранилищу файлов (потому что это блогохостинг), когда на этом самом хостинге упала БД и файловая система?
Вы никак не можете определиться и озвучить, кто же именно является целевой аудиторией вашей разработки.
Вы никак не можете определиться и озвучить, кто же именно является целевой аудиторией вашей разработки.
Смотря, что понимается под блогохостингом, если что-то типа живого журнала, то естественно тут всё на админах лежит. А если это что-то типа хостинга с предустановленным wordpress, то вполне сможет юзать. БД и файловую систему то поднимут админы, но вот их актуальность, может быть не очень.
Да я как бы давно определился, от начального и выше среднего.
Да я как бы давно определился, от начального и выше среднего.
лежит. А если это что-то типа хостинга с предустановленным wordpress, то вполне сможет юзать. БД и файловую систему то поднимут админы, но вот их актуальность, может быть не очень.
Почему «не очень»? Какая разница, что бэкапить?
Да я как бы давно определился, от начального и выше среднего.
Это не целевая аудитория.
Под актуальностью имелось ввиду, что не всегда админы хостинга могут поднять дамп нужной свежести.
Ну можно сказать для обычных юзеров, а не профи админов. Так профи в любом случае недоверчиво относятся к новым утилитам, да у них есть пачка проверенных скриптов на все случаи жизни.
Это не целевая аудитория.
Ну можно сказать для обычных юзеров, а не профи админов. Так профи в любом случае недоверчиво относятся к новым утилитам, да у них есть пачка проверенных скриптов на все случаи жизни.
Послушайте, я и вашу точку зрения понимаю, и автора. Не нужно ругаться. Он сделал отличное решение для бекапа и восстановления всяких Wordpress-блогов, Joomla/modX и прочих сайтов на shared хостинге без ssh. Он не сделал решение для матерых админов, вроде вас. Ваши непревзойденные умения пока не заменишь никаким скриптом. Более того, решение даже мне подходит с моим dedicated и админскими навыками. Просто я разработчик, а не админ. И мне гораздо интереснее создавать новые вещи, а не, простите, трахаться с настройками бекапа, несмотря на то, что квалификация есть. Потому что если сервак взорвется, то восстанавливать всю туеву хучу этих настроек придется на новом месте, потратив уйму времени. А здесь — поставил тулзу, нажал кнопку и свободен. Жена, дети, друзья, хобби, рыбалка, любимая работа — все это радуется, моему освободившемуся времени. И я радуюсь вместе с ними.
Он сделал отличное решение для бекапа и восстановления всяких Wordpress-блогов, Joomla/modX и прочих сайтов на shared хостинге без ssh. Он не сделал решение для матерых админов, вроде вас.
Вот именно поэтому я и спросил автора, какова целевая аудитория его разработки. Он не смог адекватно ответить.
Просто я разработчик, а не админ. И мне гораздо интереснее создавать новые вещи, а не, простите, трахаться с настройками бекапа, несмотря на то, что квалификация есть.
Вот именно поэтому оставьте эту работу админам вашего хостинга.
Потому что если сервак взорвется, то восстанавливать всю туеву хучу этих настроек придется на новом месте, потратив уйму времени.
Значит, у вас неправильно поставлен процесс разработки. Сервер должен настраиваться с нуля скриптом за константное время.
Вот именно поэтому оставьте эту работу админам вашего хостинга.
Во-первых, квалификация админов хостинга не всегда идеальна (только не нужно говорить, что таких выгонять нужно), во-вторых, у хостеров зачастую экономят на бэкапах, к примеру делая его раз в неделю. В-третьих, админы хостинга делают бэкап можно сказать «в лоб», просто делая бэкап всего подряд, в то время как у разного софта есть данные бэкап которых абсолютно не нужен (поисковые результаты, кэш, сессии, и прочие временные данные).
В-третьих, админы хостинга делают бэкап можно сказать «в лоб», просто делая бэкап всего подряд, в то время как у разного софта есть данные бэкап которых абсолютно не нужен (поисковые результаты, кэш, сессии, и прочие временные данные).
… и вот тут мы вспоминаем фразу про «обычных юзеров», и задумываемся — а правда ли у обычного пользователя больше квалификации, чем у админа, чтобы разобраться, что именно нужно и не нужно поднимать?
Понимаете в плане бэкапов, лучше пусть их будет два, чем ни одного. А что касается админов, то если речь не о админах какого-то крупного проекта, а обычного хостинг провайдера, то сайтов там сотни, и естественно отношение к ним, такое же конвеерное.
Во всяком случае за те годы, что я делаю дампер, жалоб на админов наслушался достаточно ;)
Во всяком случае за те годы, что я делаю дампер, жалоб на админов наслушался достаточно ;)
Понимаете в плане бэкапов, лучше пусть их будет два, чем ни одного.
Очень оптимистичное выражение. Жаль только никак не связанное с обсуждаемым вопросом.
Во всяком случае за те годы, что я делаю дампер, жалоб на админов наслушался достаточно
А я наслушался жалоб на пользователей, которым дали возможность управлять системой (=делать админскую работу), и они немедленно все испортили. После чего снова пошли к админам.
А я наслушался жалоб на пользователей, которым дали возможность управлять системой
Каким боком управление системой к бэкапам?
Прямым. Бэкап и восстановление (а особенно — частичные) — это часть действий по управлению системой.
С таким же успехом копирование файлов можно назвать управлением системой. Т.е. если какой-то «чайник» скопировал конфиг wordpress на локальный комп, а потом залил его обратно восстанавливая старые настройки, то он уже может себе скил продвинутого админа писать?
Еще раз напомню Apple Time Machine, это тоже только для продвинутых админов?
Еще раз напомню Apple Time Machine, это тоже только для продвинутых админов?
С таким же успехом копирование файлов можно назвать управлением системой.
А так и есть.
Т.е. если какой-то «чайник» скопировал конфиг wordpress на локальный комп, а потом залил его обратно восстанавливая старые настройки, то он уже может себе скил продвинутого админа писать?
Нет, не может. В этом и беда.
Еще раз напомню Apple Time Machine, это тоже только для продвинутых админов?
ATM применяется для разрозненных файлов, а не для информационных систем.
Что-то вы сами себе противоречите. Но ладно, хотите считать, что бэкап доступен только дипломированным админам, считайте, ваше дело.
Как раз наоборот, бэкап-то (должен быть) доступен не только дипломированным админам; вот только сводиться он (точнее, рестор от него) должен к «выберите дату, на которую вы хотите восстановить систему».
Во-первых, кому он должен? Можете дать ссылку на подобные требования? Или уж добавляйте «ИМХО».
Во-вторых, примерно так и будет, только в данном случае речь будет идти о сайте (а не о системе, т.е. грубо говоря public_html + mysql). Cистемы бэкапа бывают разного уровня, и не всегда нужно делать посекторный копию диска. Тот же Acronis True Image умеет делать бэкап отдельных каталогов, и восстанавливать на определенную дату, как бэкап полностью, так и отдельный файл из этого бэкапа. А дальше уже зависит от уровня пользователя, кто не понимает зачем ему восстанавливать отдельный файл, просто не будет пользоваться такой возможностью.
Во-вторых, примерно так и будет, только в данном случае речь будет идти о сайте (а не о системе, т.е. грубо говоря public_html + mysql). Cистемы бэкапа бывают разного уровня, и не всегда нужно делать посекторный копию диска. Тот же Acronis True Image умеет делать бэкап отдельных каталогов, и восстанавливать на определенную дату, как бэкап полностью, так и отдельный файл из этого бэкапа. А дальше уже зависит от уровня пользователя, кто не понимает зачем ему восстанавливать отдельный файл, просто не будет пользоваться такой возможностью.
Во-первых, кому он должен?
Пользователю.
А дальше уже зависит от уровня пользователя, кто не понимает зачем ему восстанавливать отдельный файл, просто не будет пользоваться такой возможностью.
А вот теперь мы возвращаемся к вопросу целевой аудитории и актуальности принятых вами решений.
Про что, собственно, речь с самого начала и шла.
Нормально написанный софт подходит широкому кругу пользователей. Не все пользователи должны использовать его функции на 100%.
Т.е. он вполне подойдет и блондинкам, для которых что-то типа «вернуть как было вчера», так и для более продвинутых пользователей, которые понимают, какие именно файлы в бэкапе, и которые могут восстанавливать только отдельные файлы на определенную дату. Точно также тулзу можно использовать для миграции на другой сервер.
Т.е. он вполне подойдет и блондинкам, для которых что-то типа «вернуть как было вчера», так и для более продвинутых пользователей, которые понимают, какие именно файлы в бэкапе, и которые могут восстанавливать только отдельные файлы на определенную дату. Точно также тулзу можно использовать для миграции на другой сервер.
Нормально написанный софт подходит широкому кругу пользователей.
Нет. Нормально написанный софт подходит тому кругу пользователей, на который рассчитан.
Впрочем, этот разговор действительно давно потерял смысл. Время покажет.
Заказчикам нужно делать бекап всего сайта, в том числе файлов CMS.
Так вы автор Sypex Dumper? Респект.
Неудивлюсь, если идея с SXB-форматом будет также качественно реализована.
Неудивлюсь, если идея с SXB-форматом будет также качественно реализована.
Если такой скрипт будет от создателей Sypex Dumper, учитывая полезность срипта и веру, что плохо не сделают, я бы подумал над тем, чтоб начать использовать.
Однако отмечу, что на мой взгляд просто необходимо:
1. Возможность разархивировать на десктопе.
2. Все таки не только PHP.
3. Сайт для разработчиков и пользователей, ну или хотя бы github
А так идея очень интересная, учитывая малую нагрузку и скорость работы, мне кажется вполне жизнеспособно.
Однако отмечу, что на мой взгляд просто необходимо:
1. Возможность разархивировать на десктопе.
2. Все таки не только PHP.
3. Сайт для разработчиков и пользователей, ну или хотя бы github
А так идея очень интересная, учитывая малую нагрузку и скорость работы, мне кажется вполне жизнеспособно.
Да, тему с GitHub поддерживаю. Хотя бы на уровне алгоритм и упаковщик/распаковщик в открытом доступе, а обвязка (читай «плюшки» интерфейсной части) закрыт.
1. Ну как минимум можно разархивировать используя wamp сборки (что даже предпочтительнее, потому что можно распаковать на локальный сервак).
2. Если идеая окажется достаточно популярной на PHP, то портировать её на другие языки не составит особого труда. Просто нужно с чего-то начать.
3. Сайт само так же будет, насчет github это уже будем думать после выхода беток.
2. Если идеая окажется достаточно популярной на PHP, то портировать её на другие языки не составит особого труда. Просто нужно с чего-то начать.
3. Сайт само так же будет, насчет github это уже будем думать после выхода беток.
Не забудьте добавить в packagist.org/, буду очень блогадарен
А этот скрипт — это урезанная версия какого-то полного скрипта? Просто, вопросы по коду возникают. Например, зачем Вы используете
hash_init, hash_update, hash_final, если результат потом нигде не используется?
dirs 11620
files 21338
full_size 1967.178
dup_size 32.739
archive_size 16.141
duplicates 4457
bigfiles 9592
bf_blocks 66038
bf_dup 981
bf_size 1891.764
bf_dup_size 28.275
time 272.92845
symfony2
$crc = hash('md5', $content, true);
if (!isset($this->catalog[$crc . $stat['size']])) { // Если нет такого блока, то сохраняем
Плакала моя коллекция md5-коллизий :-(
А если серьёзно, по-моему дьявол-то в деталях. Остальные форматы показывают результаты хуже, потому что им-то еще разжать может потребоваться, а не только посчитать.
Корректнее было бы сравнивать не с ZIP и RAR, а с TAR.GZ, ведь вы по сути его и придумали.
Прогнал tar -z и sxb_test на двух вариантах — один синтетический: 10 мб /dev/urandom + симлинк на него, второй — wwwroot сайта размером в гиг.
На обоих тестах tar выиграл
А именно...
## Первый тест
vos@ctfsu ~/t/sxbtest $ dd if=/dev/urandom of=testfile bs=10M count=1
vos@ctfsu ~/t/sxbtest $ ln -s testfile link
vos@ctfsu ~/t/sxbtest $ time php sxb_test.php
<source lang="php">
dirs 0
files 3
full_size 20.004
dup_size 10
archive_size 10.005
duplicates 320
bigfiles 2
bf_blocks 640
bf_dup 320
bf_size 20
bf_dup_size 10
time 0.6723
</source>
real 0m0.737s
user 0m0.628s
sys 0m0.104s
vos@ctfsu ~/t $ time rar a test.rar sxbtest
<...>
real 0m16.094s
user 0m15.481s
sys 0m0.400s
vos@ctfsu ~/t $ time zip -r test.zip sxbtest
<...>
real 0m1.069s
user 0m0.908s
sys 0m0.132s
vos@ctfsu ~/t $ time tar czvf test.tar.gz sxbtest
<...>
real 0m0.643s
user 0m0.492s
sys 0m0.120s
vos@ctfsu ~/t $ ls -la
-rw-r--r-- 1 vos vos 21027433 Jan 16 13:51 test.rar
-rw-r--r-- 1 vos vos 10490797 Jan 16 13:50 test.sxb
-rw-r--r-- 1 vos vos 10489462 Jan 16 13:51 test.tar.gz
-rw-r--r-- 1 vos vos 20976774 Jan 16 13:51 test.zip
# Можно заметить, что RAR и ZIP честно "сжали" оба файла - и реальный, и симлинк.
# SXB схавал симлинк благодаря дедупликации, а TAR - благодаря поддержке симлинков ;)
# При этом TAR сработал на 100 мсек быстрее, и архив получился чуть меньше
## Второй тест
root@zenyro /var/www/zenyro # du -s .
1015580 .
root@zenyro /var/www/zenyro # time php sxb_test.php
<source lang="php">
dirs 77
files 1038
full_size 987.905
dup_size 0.46
archive_size 935.769
duplicates 175
bigfiles 146
bf_blocks 31505
bf_dup 13
bf_size 982.087
bf_dup_size 0.385
time 114.39332
</source>
real 1m54.616s
user 1m6.716s
sys 0m3.700s
root@zenyro /var/www # time tar czvf test.tar.gz zenyro
<...>
real 1m4.614s
user 0m56.044s
sys 0m3.380s
root@zenyro /var/www # ls -la
-rw-r--r-- 1 root root 981224934 2013-01-16 13:57 test.sxb
-rw-r--r-- 1 root root 980944407 2013-01-16 13:59 test.tar.gz
# Снова TAR чуть меньше, и быстрее на 10 секунд
# Не говоря уже о том что его можно распаковать :)
И еще
Глупая мысль о том, как спасти мир и не изобрести велосипед
По сути, придуманный вами формат ближе всего к TAR с навешанным GZ, поэтому имхо стоит просто взять формат TAR за основу и прикрутить к нему недостающие фишки.
Во-первых, его стоит взять потому что он изначально заточен под никсы, и в нем уже есть все что нужно для полноценного бекапа сервера. В вашем формате пришлось бы учитывать тонну нюансов, по типу симлинков, прав к файлам и тд.
Во-вторых, сам формат tar супер-легкий для понимания и реализации, писать архивы в виде TAR-а легче чем выдумывать свой велосипед со всеми фичами, которые вы перечислили, и при этом тарник можно будет распаковать где угодно. К тому же, я слабо представляю как вы собираетесь совместить некоторые фичи, например «Непрерывный архив» и «Наличие индекса + Быстрый случайный доступ к содержимому»
А вот если добавить в TAR то, чего ему не хватает, вполне может получиться крутое решение. Например, если реализовать в вашем скрипте «Сохранение потоков в архив» для TARа, это легко может стать «киллер-фичей». И это по сложности ничем не отличается от сохранения потоков в своем велосипедном формате. Ну или тот же «Контроль целостности содержимого» в виде файлика в md5-суммами файлов внутри архива. Главное, чтобы не ломалась спецификация и получившийся архив можно было распаковать без вашей тулзы.
Ладно, чёт я увлекся :) Заинтересовал ваш подход!
Желаю вам следования имеющимся спецификациям =)
Во-первых, его стоит взять потому что он изначально заточен под никсы, и в нем уже есть все что нужно для полноценного бекапа сервера. В вашем формате пришлось бы учитывать тонну нюансов, по типу симлинков, прав к файлам и тд.
Во-вторых, сам формат tar супер-легкий для понимания и реализации, писать архивы в виде TAR-а легче чем выдумывать свой велосипед со всеми фичами, которые вы перечислили, и при этом тарник можно будет распаковать где угодно. К тому же, я слабо представляю как вы собираетесь совместить некоторые фичи, например «Непрерывный архив» и «Наличие индекса + Быстрый случайный доступ к содержимому»
А вот если добавить в TAR то, чего ему не хватает, вполне может получиться крутое решение. Например, если реализовать в вашем скрипте «Сохранение потоков в архив» для TARа, это легко может стать «киллер-фичей». И это по сложности ничем не отличается от сохранения потоков в своем велосипедном формате. Ну или тот же «Контроль целостности содержимого» в виде файлика в md5-суммами файлов внутри архива. Главное, чтобы не ломалась спецификация и получившийся архив можно было распаковать без вашей тулзы.
Ладно, чёт я увлекся :) Заинтересовал ваш подход!
Желаю вам следования имеющимся спецификациям =)
Первым делом, спасибо за комментарий и тест. А теперь прокомментирую.
Это всего лишь упрощенный тестовый скрипт, так как, как вы могли заметить у него даже каталога нет.
Что касается коллизий, поделитесь, особенно интересуют коллизии для фрагментов одинакового размера, с одинаковым md5 и crc32.
Опять же, это как бы не конечный формат, сейчас это просто содержимое файлов слитое в один gzip файл. Еще раз обратите внимание что, меня интересовало количество дубликатов на реальных данных. Предложенный формат будет скорее 7z напоминать, от TAR там разве, deflate сжатие, да и то не совсем от tar.
Что касается тестов с таром, то вполне возможно в таком виде он и выигрывает по скорости, что касается сжатия (то это просто из-за большего уровня сжатия gzip). Но есть несколько нюансов, tar не считает попутно md5 хэши для файлов и блоков. И второй нюанс, мы говорим о сишной программе которая шлифовалась годами, а с другой стороны php-скрипт (издавна считающийся весьма не быстрым языком). Так, что проигрыш в скорости в 15-20%, это уже можно сказать успех. Тем более, что в конечной версии, где плохо сжимаемые данные будут писаться в блоки без сжатия, скорость будет выше.
На самом деле всё просто, непрерывный архив не обязательно делась полностью непрерывным. Достаточно поделить архив на блоки скажем по 10 мегабайт, в каталоге у нас указывается в каком блоке файл находится, и смещение файла в блоке. Т.е. чтобы достать файл с конца архива в гиг, мы читаем грубо говоря последние 10 метров.
Что касается потоков в TAR, тут основная проблема в заголовках. В моем варианте заголовков перед файлами просто не будет, они все в каталоге, а каталог пишется в конец файла когда всё уже добавлено и вся информация известа.
Это всего лишь упрощенный тестовый скрипт, так как, как вы могли заметить у него даже каталога нет.
Что касается коллизий, поделитесь, особенно интересуют коллизии для фрагментов одинакового размера, с одинаковым md5 и crc32.
Корректнее было бы сравнивать не с ZIP и RAR, а с TAR.GZ, ведь вы по сути его и придумали.
Опять же, это как бы не конечный формат, сейчас это просто содержимое файлов слитое в один gzip файл. Еще раз обратите внимание что, меня интересовало количество дубликатов на реальных данных. Предложенный формат будет скорее 7z напоминать, от TAR там разве, deflate сжатие, да и то не совсем от tar.
Что касается тестов с таром, то вполне возможно в таком виде он и выигрывает по скорости, что касается сжатия (то это просто из-за большего уровня сжатия gzip). Но есть несколько нюансов, tar не считает попутно md5 хэши для файлов и блоков. И второй нюанс, мы говорим о сишной программе которая шлифовалась годами, а с другой стороны php-скрипт (издавна считающийся весьма не быстрым языком). Так, что проигрыш в скорости в 15-20%, это уже можно сказать успех. Тем более, что в конечной версии, где плохо сжимаемые данные будут писаться в блоки без сжатия, скорость будет выше.
К тому же, я слабо представляю как вы собираетесь совместить некоторые фичи, например «Непрерывный архив» и «Наличие индекса + Быстрый случайный доступ к содержимому»
На самом деле всё просто, непрерывный архив не обязательно делась полностью непрерывным. Достаточно поделить архив на блоки скажем по 10 мегабайт, в каталоге у нас указывается в каком блоке файл находится, и смещение файла в блоке. Т.е. чтобы достать файл с конца архива в гиг, мы читаем грубо говоря последние 10 метров.
Что касается потоков в TAR, тут основная проблема в заголовках. В моем варианте заголовков перед файлами просто не будет, они все в каталоге, а каталог пишется в конец файла когда всё уже добавлено и вся информация известа.
Но есть несколько нюансов, tar не считает попутно md5 хэши для файлов и блоков.
Что касается потоков в TAR, тут основная проблема в заголовках.
ls -lR * > .index; echo > .checksumm; for i in `cat index| awk '{print $9}'`; do md5sum $i >> .checksumm; done; tar cvf backup.tar *; zip backup.zip backup.tar .index .checksumm
Небольшой однострочник, который, как мне кажется, обходит мешающие вам проблемы tar && zip и при этом не создающий каких-либо серьезных велосипедов
Ничего он не решает, вывод ls в виде текста сложно назвать индексом. Во-первых он в текстом виде, что усложняет (читай замедляет) его парсинг. Во-вторых, задача индекса по имени файла указать, где конкретно в контейнере находится искомый файл, чтобы простым fseek'ом найти сам файл (чтобы использовать все преимущества случайного доступа).
Да и вообще весь этот unix way будет тормозить, потому что одни и те операции выполняются по несколько раз:
Да и вообще весь этот unix way будет тормозить, потому что одни и те операции выполняются по несколько раз:
- сначала вам нужно получить список файлов рекурсивно обойдя все подкаталоги и получив их атрибуты для «индекса»;
- потом отдельно будет парситься этот файл и по нему читаться файлы и строиться md5;
- теперь tar делает листинг каталога и достает все атрибуты, читает файлы и сохраняет их в tar, в итоге получаем массивный несжатый образ сайта;
- и в конце концов мы это дело пакуем в архив zip.
В итоге получается масса лишних операций с файловой системой (а файловая система и так не самое быстрое место), ну и конечно сами файлы нам получается нужно прочитать 3 раза, сначала это сделает md5, потом tar, а потом все файлы в одной куче прочитает еще и zip. Итого, чтобы сделать архив сайта на 200 МБ, вам понадобится прочитать 600 МБ инфы, и плюс записать временный файл на 200 МБ.
В моем же варианте вы прочитаете только один раз 200 МБ, и сразу пишете в готовый файл (можно даже сразу в облачное хранилище писать).
в принципе это верная мысль, можно было расширить существующую реализацию zip. Не думаю что было бы сложнее исправить формат времени и добавить шифрование имен файлов. У непрерывных архивов есть и плюсы и минусы.
Результаты тестов в статье меня смущают — примитивная дедупликация внезапно уделала все архиваторы и по времени и по сжатию, я бы себе сразу задал вопрос все ли в порядке.
Результаты тестов в статье меня смущают — примитивная дедупликация внезапно уделала все архиваторы и по времени и по сжатию, я бы себе сразу задал вопрос все ли в порядке.
И толку от этого расширения zip если его все равно никто понимать не будет? TAR.GZ по сути является непрерывным архивом и уже десятки лет используется. Другое дело, что в нем этот непрерывный архив не оптимизирован для быстрой работы с содержимым. Тем более, что у бэкапа и архива несколько разные предназначения.
У архиваторов обычно редко стоит задача именно быстро сжимать данные. Да и я же специально выложил скриптик, чтобы протестить в реальных условиях.
У архиваторов обычно редко стоит задача именно быстро сжимать данные. Да и я же специально выложил скриптик, чтобы протестить в реальных условиях.
Просто вы перечислили минусы зипа, но их все можно исправить, ведь все равно это будет новый формат и кроме вашей программы никто не будет его понимать. Ну и получится шифрование есть, индекс есть, сжатие есть, учитывая, что это бэкап, то достаточно.
Вас не удивляет скорость и качество сжатия? Ну на самом деле, показан результат лучше все известных архиваторов, над которыми работали годами десятки людей. Единственный вариант напрашивается — слишком много одинаковых файлов, а в этом случае проще считать хэш сразу от всего файла и не усложнять алгоритм.
Вас не удивляет скорость и качество сжатия? Ну на самом деле, показан результат лучше все известных архиваторов, над которыми работали годами десятки людей. Единственный вариант напрашивается — слишком много одинаковых файлов, а в этом случае проще считать хэш сразу от всего файла и не усложнять алгоритм.
У zip нет непрерывных архивов, что учитывая наличие на сайтах большого количества мелких файлов, даёт большой проигрыш по сжатию. Предложенный формат скорее ближе к 7z, чем к zip.
Качество сжатия не удивляет, посмотрите архивы tar.gz, они значительно лучше, чем zip сжимаются. А что касается rar и 7z, то у них основное усилие разработчики тратят на режимы с максимальным сжатием. В случае с SXB нет максимального сжатия, есть очень хорошее сжатие за минимальное время. Что, считаю, для бэкапов очень полезно, так как делает нагрузку на сервер во время бэкапа минимальной.
Качество сжатия не удивляет, посмотрите архивы tar.gz, они значительно лучше, чем zip сжимаются. А что касается rar и 7z, то у них основное усилие разработчики тратят на режимы с максимальным сжатием. В случае с SXB нет максимального сжатия, есть очень хорошее сжатие за минимальное время. Что, считаю, для бэкапов очень полезно, так как делает нагрузку на сервер во время бэкапа минимальной.
Не хотите выложить код на Github? Думаю многие бы присоединились к развитию продукта.
dirs 333
files 552
full_size 9.322
dup_size 0.008
archive_size 0.538
duplicates 57
bigfiles 54
bf_blocks 258
bf_dup 0
bf_size 7.258
bf_dup_size 0
time 5.58459
Kohana, папка
application
dirs 51368
files 94823
full_size 1968.667
dup_size 1210.483
archive_size 302.122
duplicates 95438
bigfiles 4817
bf_blocks 49942
bf_dup 34714
bf_size 1470.996
bf_dup_size 1027.673
time 143.4513
zip -6 выдал 1158МБ за 79 секунд
Там было много всего, включая бинарники :)
Modx Revo
На том же контенте на Инфобоксе скрипт вернул 504.
dirs 1762
files 9308
full_size 74.562
dup_size 11.541
archive_size 40.567
duplicates 3636
bigfiles 319
bf_blocks 1769
bf_dup 156
bf_size 49.66
bf_dup_size 4.204
time 38.93353
На том же контенте на Инфобоксе скрипт вернул 504.
Скажите, а чем плох Obnam?
Его не тестил, но судя по описанию очередная обертка над rsync. Отсюда те же недостатки. К примеру, с базами данных дедупликация не работает, по банальной причине. Когда делаешь дамп стандартным mysqldump, в начале файла добавляется заголовок с временем создания файла, так же в дампе в CREATE TABLE постоянно меняется AUTO_INCREMENT, ну и естественно из-за увеличения количества записей в одной таблице, смещаются все остальные. В итоге блоки меняются, когда измененных данных всего пару строк.
В предложенном мной варианте данные каждой таблицы сохраняются независимо, поэтому дедупликация будет работать значительно лучше.
В предложенном мной варианте данные каждой таблицы сохраняются независимо, поэтому дедупликация будет работать значительно лучше.
(Сорри за поздний ответ, спамоловилка скушала нотификацию.)
Нет, obnam не имеет ничего общего с rsync. Он делит данные на блоки, которые уже потом дедуплицирует. Кстати, Вы слабо осведомлены насчёт rsync, он как раз детектирует сдвиги. Почитайте диссертацию Триджелла, там интересно.
Нет, obnam не имеет ничего общего с rsync. Он делит данные на блоки, которые уже потом дедуплицирует. Кстати, Вы слабо осведомлены насчёт rsync, он как раз детектирует сдвиги. Почитайте диссертацию Триджелла, там интересно.
Вообще я в курсе насчет того, что у rsync детектируют сдвиги я об этом писал. В том числе знаю как именно он это делает. Проблема в том что из-за формата sql-дампа, всё равно будет куча лишних блоков, в которых по сути ничего не изменилось.
Ясно. Речь в первую очередь была о том, что obnam не связан с rsync.
Кстати, liw.fi/obnam/faq/dedup/
Кстати, liw.fi/obnam/faq/dedup/
В моем случае не будет использоваться стандартный SQL дамп, я об этом написал в отдельной статье habrahabr.ru/post/167469/
Правда с момента публикации статьи я пошел дальше, и сейчас в разработке оригинальная фишка RAW бэкап для MySQL. Там будет использоваться собственный MySQL-клиент, который работает напрямую с MySQL-сервером, и без лишних преобразований сохраняет данные сразу в бэкап. В итоге скорость работы в 2 с лишним раза выше mysqldump, плюс сам бэкап значительно лучше подходит для дедупликации.
Правда с момента публикации статьи я пошел дальше, и сейчас в разработке оригинальная фишка RAW бэкап для MySQL. Там будет использоваться собственный MySQL-клиент, который работает напрямую с MySQL-сервером, и без лишних преобразований сохраняет данные сразу в бэкап. В итоге скорость работы в 2 с лишним раза выше mysqldump, плюс сам бэкап значительно лучше подходит для дедупликации.
Знаете ли вы, что существует xar ( ru.wikipedia.org/wiki/Xar_(%D0%B0%D1%80%D1%85%D0%B8%D0%B2%D0%B0%D1%82%D0%BE%D1%80), code.google.com/p/xar )?
Он поддерживает большое число фич из тех, которые вы назвали + юзается в MacOS и в RetHat-based distros для .rpm-пакетов.
У меня куча вопросов про дедупликацию. Вы сами придумали идею дедупликации? А термин ваш? Где можно ещё почитать про эту дедупликацию?
Каким именно образом делается блочная дедупликация из вот этих двух вариантов:
1. Файл (или весь архив, но до сжатия) просто в тупую делится на блоки фиксированного размера, затем эти блоки сравниваются (например, путём сравнения хешей) и лишние блоки выкидываются. При этом начала блоков расположены (в исходном, несжатом файле, или в несжатом архиве) по отношению к началу файла всегда на смещение кратное длине блока.
2. Не всё так просто :) Используется какая-то более сложная схема или схема с какими-то оптимизациями. В результате архиватор может обнаружить совпадающие блоки в случае если они расположены относительно начала файла необязательно на смещение кратное длине блока.
Если верен второй вариант, то мне хочется узнать об этой дедупликации больше. Будет идеально, если вы напишете статью на эту тему. Вообще, если верен второй вариант, то дедупликация нетривиальна с алгоритмической точки зрения. Поэтому в этом случае у меня ещё несколько вопросов. Есть ли статьи из области теории алгоритмов на тему дедупликации? Сравниваются ли блоки, которые расположены в разных файлах (т. е. дедупликация блоков происходит на уровне файла или архива)? Какие ещё есть свободные архиваторы с поддержкой дедупликации?
Он поддерживает большое число фич из тех, которые вы назвали + юзается в MacOS и в RetHat-based distros для .rpm-пакетов.
У меня куча вопросов про дедупликацию. Вы сами придумали идею дедупликации? А термин ваш? Где можно ещё почитать про эту дедупликацию?
Каким именно образом делается блочная дедупликация из вот этих двух вариантов:
1. Файл (или весь архив, но до сжатия) просто в тупую делится на блоки фиксированного размера, затем эти блоки сравниваются (например, путём сравнения хешей) и лишние блоки выкидываются. При этом начала блоков расположены (в исходном, несжатом файле, или в несжатом архиве) по отношению к началу файла всегда на смещение кратное длине блока.
2. Не всё так просто :) Используется какая-то более сложная схема или схема с какими-то оптимизациями. В результате архиватор может обнаружить совпадающие блоки в случае если они расположены относительно начала файла необязательно на смещение кратное длине блока.
Если верен второй вариант, то мне хочется узнать об этой дедупликации больше. Будет идеально, если вы напишете статью на эту тему. Вообще, если верен второй вариант, то дедупликация нетривиальна с алгоритмической точки зрения. Поэтому в этом случае у меня ещё несколько вопросов. Есть ли статьи из области теории алгоритмов на тему дедупликации? Сравниваются ли блоки, которые расположены в разных файлах (т. е. дедупликация блоков происходит на уровне файла или архива)? Какие ещё есть свободные архиваторы с поддержкой дедупликации?
У меня куча вопросов про дедупликацию. Вы сами придумали идею дедупликации? А термин ваш? Где можно ещё почитать про эту дедупликацию?
В википедии есть немного.
Ещё есть файловая система с автоматической дедубликацией, которую можно подключить через Fuse.
Если верен второй вариант, то мне хочется узнать об этой дедупликации больше.
Вам нужно почитать информацию о сравнении бинарных файлов — сравнение на уровне блоков, которые могут быть расположены с разным смещением.
У него документация по формату не очень, да и индекс в виде xml мне не очень нравится (это неплохо в плане расширяемости, но со скоростью у такого варианта не очень).
Про дедупликацию, её уже давно придумали, в wiki можно почитать (лучше в английской версии, в русской значительно сократили описание).
Что касается моего варианта, то на начальном этапе будет первый вариант, с фиксированным размещением блоков. Потом возможно будет вариант с плавающими блоками (но тут нужно тестить, чтобы не сильно тормозило). Про плавающие блоки можно почитать в доках rsync (кстати был приятно удивлен, что мыслил так же как и автор rsync).
Более простой вариант (который я думаю реализовывать на втором этапе), вместе с хэшами блоков (для того чтобы значительно уменьшить вероятность коллизии, делается CRC32 + MD5 для каждого блока) кроме того для каждого блока сохраняется первые и последние 4-5 байт блока. в таком случае если у нас хэши блока не совпадают, то пытаемся найти эту самую последовательность байт из начала/конца блока, и если находим, то сверяем хэши (так в принципе работали первые версии rsync).
Более продвинутый метод скользящий (или кольцевой) хэш, но пока не знаю как он поведет себя на php.
Про дедупликацию, её уже давно придумали, в wiki можно почитать (лучше в английской версии, в русской значительно сократили описание).
Что касается моего варианта, то на начальном этапе будет первый вариант, с фиксированным размещением блоков. Потом возможно будет вариант с плавающими блоками (но тут нужно тестить, чтобы не сильно тормозило). Про плавающие блоки можно почитать в доках rsync (кстати был приятно удивлен, что мыслил так же как и автор rsync).
Более простой вариант (который я думаю реализовывать на втором этапе), вместе с хэшами блоков (для того чтобы значительно уменьшить вероятность коллизии, делается CRC32 + MD5 для каждого блока) кроме того для каждого блока сохраняется первые и последние 4-5 байт блока. в таком случае если у нас хэши блока не совпадают, то пытаемся найти эту самую последовательность байт из начала/конца блока, и если находим, то сверяем хэши (так в принципе работали первые версии rsync).
Более продвинутый метод скользящий (или кольцевой) хэш, но пока не знаю как он поведет себя на php.
Какие ещё есть свободные архиваторы с поддержкой дедупликации?
В архиваторах особо не используется, так как архиваторы рассчитаны на разовую упаковку файлов. В то время, как среди программ для бэкапа это довольно распространенное явление. Так как в таком случае достигается значительная экономия места. Свободные бэкаперы в основном используют rsync для дедупликации.
Я тоже недавно начал писать тулзу, который делает (в вашей терминологии) дедупликацию.
Я её написал, чтобы можно было сжать несколько крупных бинарников за счёт наличия в них повторяющихся частей (например, .iso-шников разных windows'ов). При этом мне не важно, сколько времени займёт дедупликация и сколько оперативы будет кушать тулза. Главное, чтоб объём архива был минимальным. Собственно цель такая: добиться, чтобы архив поместился на Dropbox.
Тулза делает только дедупликацию и ничего более. Он не контейнер (т. е. не может соединять файлы в один) и он не делает никакого другого сжатия. Поэтому, если нужно сжать несколько файлов, я сперва соединяю их tar'ом, потом делаю дедупликацию моей тулзой, потом сжимаю, скажем, .xz
На сегодня тулза не умеет делать дедупликацию, она лишь может показывать, на сколько данные уменьшились бы, если бы дедупликация проводилась (я так понял, что ваша тулза находится на таком же этапе разработки)
На удивление тулза (без последующего сжатия другим компрессором) показывает результаты лучшие, чем .xz! При чём намного лучшие (832 MB против 983 MB для .xz). Правда лишь для специально подобранных данных :) (.tar с двумя образами visual studio).
И при этом программа жрёт огроменное количество оперативы (в несколько раз превышающее объём исходных данных!)
Тулза делает блочную дедупликацию, причём она выполняет поиск одинаковых блоков среди всех блоков данной длины, расположенных на любом смещении относительно начала исходного файла.
Именно поэтому мне интересны теоритические результаты в области дедупликации (заменить мой жрущий алгоритм на нормальный) и готовые прожки (чтоб не изобретать велосипед).
Если хотите могу выслать код, выслать таблицы о том, как моя тулза сжимает на разных входных данных с разными размерами блоков + сравнения с другими архиваторами типа .xz. Также если хотите могу протестить вашу тулзу на своих данных. За одно узнаем, чья тулза сжимает лучше.
Я её написал, чтобы можно было сжать несколько крупных бинарников за счёт наличия в них повторяющихся частей (например, .iso-шников разных windows'ов). При этом мне не важно, сколько времени займёт дедупликация и сколько оперативы будет кушать тулза. Главное, чтоб объём архива был минимальным. Собственно цель такая: добиться, чтобы архив поместился на Dropbox.
Тулза делает только дедупликацию и ничего более. Он не контейнер (т. е. не может соединять файлы в один) и он не делает никакого другого сжатия. Поэтому, если нужно сжать несколько файлов, я сперва соединяю их tar'ом, потом делаю дедупликацию моей тулзой, потом сжимаю, скажем, .xz
На сегодня тулза не умеет делать дедупликацию, она лишь может показывать, на сколько данные уменьшились бы, если бы дедупликация проводилась (я так понял, что ваша тулза находится на таком же этапе разработки)
На удивление тулза (без последующего сжатия другим компрессором) показывает результаты лучшие, чем .xz! При чём намного лучшие (832 MB против 983 MB для .xz). Правда лишь для специально подобранных данных :) (.tar с двумя образами visual studio).
И при этом программа жрёт огроменное количество оперативы (в несколько раз превышающее объём исходных данных!)
Тулза делает блочную дедупликацию, причём она выполняет поиск одинаковых блоков среди всех блоков данной длины, расположенных на любом смещении относительно начала исходного файла.
Именно поэтому мне интересны теоритические результаты в области дедупликации (заменить мой жрущий алгоритм на нормальный) и готовые прожки (чтоб не изобретать велосипед).
Если хотите могу выслать код, выслать таблицы о том, как моя тулза сжимает на разных входных данных с разными размерами блоков + сравнения с другими архиваторами типа .xz. Также если хотите могу протестить вашу тулзу на своих данных. За одно узнаем, чья тулза сжимает лучше.
Это не мой термин, в wiki есть статья на эту тему. Я вообще думал что нужно писать дедубликация, типа от слова «дубликат», но оказывается, что правильнее дедупликация от латинского duplicatus.
Я там ответил в предыдущем комменте, со ссылками насчет алгоритмов. Но обычно дедупликация с плавающим блоком используется для определения изменений в файле, а не для сквозного по всем файлам.
В общем думаю вам нужно посмотреть rsync.
Я там ответил в предыдущем комменте, со ссылками насчет алгоритмов. Но обычно дедупликация с плавающим блоком используется для определения изменений в файле, а не для сквозного по всем файлам.
В общем думаю вам нужно посмотреть rsync.
А почему не просто 7zip/bz2/zip с определённой структурой архива?
IMHO, вот эти фичи — не есть функции архива/архиватора:
* Инкрементальный бэкап на блочном уровне
* Дополнительные типы данных (а не только файлы и каталоги)
* Версионность
В каких из других архивов эти фичи есть?
IMHO, вот эти фичи — не есть функции архива/архиватора:
* Инкрементальный бэкап на блочном уровне
* Дополнительные типы данных (а не только файлы и каталоги)
* Версионность
В каких из других архивов эти фичи есть?
Так в том то и дело, что в данном случае не делается архиватор, делается именно формат для бэкапа. В который регулярно добавляются файлы, и в котором нужна возможность выбрать файл, и потом тут же показывается сколько есть его версий и можно восстановить именно нужную версию.
А указанные фичи есть именно в специализированных форматах для бэкапа. Как например, CBU (формат Comodo Backup), TIB (формат Actonis True Image).
Так что вполне естественно что в архиваторах такого функционала нет, так как там нет связанных архивов.
А указанные фичи есть именно в специализированных форматах для бэкапа. Как например, CBU (формат Comodo Backup), TIB (формат Actonis True Image).
Так что вполне естественно что в архиваторах такого функционала нет, так как там нет связанных архивов.
А по «велосипедности» у меня больше вопросов именно к функциям — велосипед должен ездить, а насос качать. В данном варианте мне кажется, что насосы приварены к велосипеду.
А программа бэкапа должна удобно делать бэкапы, а не предлагать пользователю разбираться с конфигами, искать готовые скрипты в инете и т.п.
Т.е. идея состоит в том чтобы владельцу блога на wordpress, достаточно было установить плагин, причем для разных CMS будут свои готовые профили (чтобы не бэкапить различные временные файлы, поисковый кэш, и прочую ненужную инфу), и выбрать одно или несколько хранилищ. Т.е. речь идет в первую очередь о массовом продукте.
Т.е. идея состоит в том чтобы владельцу блога на wordpress, достаточно было установить плагин, причем для разных CMS будут свои готовые профили (чтобы не бэкапить различные временные файлы, поисковый кэш, и прочую ненужную инфу), и выбрать одно или несколько хранилищ. Т.е. речь идет в первую очередь о массовом продукте.
сам велосипедостроитель, за что имею в своих статьях много минусов, по этому идею поддерживаю
НО:
имеет смысл реализовать Си утилиту/библиотеку и на ее основе сделть РНР расширение
РНР-реализация — это промежуточно-исследовательский вариант
спасибо Вам и удачи в реализации полезной идеи.
НО:
имеет смысл реализовать Си утилиту/библиотеку и на ее основе сделть РНР расширение
РНР-реализация — это промежуточно-исследовательский вариант
спасибо Вам и удачи в реализации полезной идеи.
У решения на PHP есть преимущество в том, что его легко поставить на любую популярную CMS (все-таки среди готовых решений PHP пока вне конкуренции), если будет отдельная СИ утилита/библиотека, то она станет очередной СИ-библиотекой для бэкапа, которые смогут пользоваться далеко не все пользователи.
Т.е. пока задача вывести именно массовое PHP решение, как показывают тесты оно не сильно уступает в скорости сишным вариантам, так что переход на СИ будет скорее вторым этапом, если сама PHP-утилита окажется успешной.
Т.е. пока задача вывести именно массовое PHP решение, как показывают тесты оно не сильно уступает в скорости сишным вариантам, так что переход на СИ будет скорее вторым этапом, если сама PHP-утилита окажется успешной.
у меня другое видинье, но конечно решать Вам:
делаем удачное сишное решение, в ввиде библиотеки, более производительнее с вышеописанными преимуществами.
портируем его (будут его уже портировать специалисты по другим языкам, если поймут что это решение/формат лучше, производительнее и т.д.) на другие языки.
делаем удачное сишное решение, в ввиде библиотеки, более производительнее с вышеописанными преимуществами.
портируем его (будут его уже портировать специалисты по другим языкам, если поймут что это решение/формат лучше, производительнее и т.д.) на другие языки.
Библиотек на СИ различных и так хватает. Но во-первых, библиотека на СИ это не массовое решение, во-вторых, как раз хочется сделать комплексное решение и удобным интерфейсом, тут как раз многие плюшки возможны благодаря этой комплексности. Да и плюс, чтобы можно было зарегить приложение для получения OAuth авторизации в облачных хранилищах.
У меня вопрос про блочную дедубликацию. (В исходник смотрел, но я не специалист.)
На сколько я понял файл делится на блоки, блоки хешируются, по хешам смотрим на дубликаты.
Т.е. я правильно понимаю, что если у меня лежит, скажем CSV файл с данными на 10 Мб, и в нем в первой строке добавилась пара байт, то такой файл уже не будет считаться дубликатом не по одному из блоков, т.к. блочная граница сместилась на несколько байт?
На сколько я понял файл делится на блоки, блоки хешируются, по хешам смотрим на дубликаты.
Т.е. я правильно понимаю, что если у меня лежит, скажем CSV файл с данными на 10 Мб, и в нем в первой строке добавилась пара байт, то такой файл уже не будет считаться дубликатом не по одному из блоков, т.к. блочная граница сместилась на несколько байт?
dirs 1501
files 15149
full_size 343.413
dup_size 17.099
archive_size 228.128
duplicates 3261
bigfiles 1610
bf_blocks 9064
bf_dup 287
bf_size 255.706
bf_dup_size 7.805
time 117.04076
files 15149
full_size 343.413
dup_size 17.099
archive_size 228.128
duplicates 3261
bigfiles 1610
bf_blocks 9064
bf_dup 287
bf_size 255.706
bf_dup_size 7.805
time 117.04076
Сообщите пожалуйста, спустя год после начала разработки есть какие-нибудь результаты или хотя бы более-менее рабочие версии?
И хотел добавить, что большинству вебмастеров не так важна дедупликация и инкрементальные бекапы, им просто нужен удобный скрипт, который сразу может сделать бекап всех файлов сайта+базы в один файлик, и чтобы работало на большинстве хостингов:
— скопировал файл скрипта на хостинг по FTP, зашел в веб-интерфейс, ввел логин-пароль, нажал кнопку, покурил 10 минут, закачал к себе бекап, удалил файл и бекап с хостинга.
Так что хотелось бы увидеть облегченную версию этой утилиты, без лишних фишек.
И хотел добавить, что большинству вебмастеров не так важна дедупликация и инкрементальные бекапы, им просто нужен удобный скрипт, который сразу может сделать бекап всех файлов сайта+базы в один файлик, и чтобы работало на большинстве хостингов:
— скопировал файл скрипта на хостинг по FTP, зашел в веб-интерфейс, ввел логин-пароль, нажал кнопку, покурил 10 минут, закачал к себе бекап, удалил файл и бекап с хостинга.
Так что хотелось бы увидеть облегченную версию этой утилиты, без лишних фишек.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разрабатываем новый формат файла для бэкапа сайтов