А вот так могёт?
Добавлено: 28 апр 2006, 22:18Здравствуйте, уважаемые разработчики APBackUp! Изучая Вашу программу, пришёл к неутешительному выводу, что нет таки в мире совершенства :(
Предложенная Вами документация весьма приблизительно описывает реализованный в программе алгоритм ротации архивов. Хотелось бы получить исчерпывающее описание сего действа. Понятно, конечно, что "удаляется самый старый", НО! Старый КАКОЙ? Полный (FULL)? Дифференциальный (DIFFERENT)? Дополняющий (INCREMENT)? Слишком много непоняток для столь серьёзного дела, как бэкап.
А к разговору этому меня подвигло не желание поглумиться, отнюдь, но решить наконец с Вашей, вероятно, помощью, одну из величайших проблем абсолютного большинства современных бэкап-автоматов, а именно:
Представьте некий объём данных, достаточный для того, чтобы вопрос о резервном копировании оного решался именно с помощью специально выделенного дискового пространства. Итак, однажды делаем FULL BACKUP, далее, ведём INCR историю (DIFы для простоты понимания сейчас не рассматриваем), отслеживая изменения данных в течении, например, месяца. И вот нам пора-бы удалить самый старый INCR, НО! Что делать с FULL? Удалять нельзя, это понятно. Генерить новый? А кому это нужно? Ведь вполне работоспособный FULL у нас уже есть, и если надо, мы вполне можем скопировать его, куда душе угодно, продолжив работу с имеющимся материалом! Вот оно, "бутылочное горлышко" почти всех доступных на сегодня бэкапных инструментов! Самым логичным решением представляется некая операция "слияния" имеющегося FULL со старейшим INCR, которая просто "сместит" время создания FULL архива, освободив место для новых версий INCR. Конечно, для корректной отработки подобного алгоритма нам придётся отслеживать не только новые и изменившиеся данные, но и сохранять в INCR информацию об УДАЛЁННЫХ файлах (полное имя, размер, простейшая контрольная сумма ... ???), делая своеобразные "скриншоты" изменений в файловой системе. Здесь интересно заметить, что многие современные бэкап-автоматы обладают подобным функционалом (им это нужно, чтобы реализовать простой алгоритм восстановления файловой системы "по состоянию на на момент n-го бэкапа" а заодно драматическим образом ускорить операции анализа данных), однако напрашивающаяся функция "быстрого обновления FULL за счёт старейшего INCR" нигде не рализована!
Да, предложенная идея сулит долгие ночи над программным кодом, но зато какие открываются перспективы, а? Мало того, что APBackUp рискует стать ПЕРВОЙ программой, реализующей ПОЛНОЦЕННЫЙ алгоритм "скользящего бэкапа", так ещё и функционал можно существенно расширить за счёт применения этих самых "скриншотов"! Например, появляется реальная возможность отслеживать копии файлов, разбросанные по разным местам хранилища, здорово экономя на объёмах и времени их архивирования/восстановления, сохраняя лишь первую копию такого файла, заменив остальные ссылками в этих самых "скриншотах"... Да, задача здорово превосходит функционал навороченного шедулера, коим на сегодня и является, на мой взгляд APBackUp... Однако, лиха беда начало! С нетерпением буду ждать Вашего ответа.... Удачи! С уважением, DenniOnLine.
Предложенная Вами документация весьма приблизительно описывает реализованный в программе алгоритм ротации архивов. Хотелось бы получить исчерпывающее описание сего действа. Понятно, конечно, что "удаляется самый старый", НО! Старый КАКОЙ? Полный (FULL)? Дифференциальный (DIFFERENT)? Дополняющий (INCREMENT)? Слишком много непоняток для столь серьёзного дела, как бэкап.
А к разговору этому меня подвигло не желание поглумиться, отнюдь, но решить наконец с Вашей, вероятно, помощью, одну из величайших проблем абсолютного большинства современных бэкап-автоматов, а именно:
Представьте некий объём данных, достаточный для того, чтобы вопрос о резервном копировании оного решался именно с помощью специально выделенного дискового пространства. Итак, однажды делаем FULL BACKUP, далее, ведём INCR историю (DIFы для простоты понимания сейчас не рассматриваем), отслеживая изменения данных в течении, например, месяца. И вот нам пора-бы удалить самый старый INCR, НО! Что делать с FULL? Удалять нельзя, это понятно. Генерить новый? А кому это нужно? Ведь вполне работоспособный FULL у нас уже есть, и если надо, мы вполне можем скопировать его, куда душе угодно, продолжив работу с имеющимся материалом! Вот оно, "бутылочное горлышко" почти всех доступных на сегодня бэкапных инструментов! Самым логичным решением представляется некая операция "слияния" имеющегося FULL со старейшим INCR, которая просто "сместит" время создания FULL архива, освободив место для новых версий INCR. Конечно, для корректной отработки подобного алгоритма нам придётся отслеживать не только новые и изменившиеся данные, но и сохранять в INCR информацию об УДАЛЁННЫХ файлах (полное имя, размер, простейшая контрольная сумма ... ???), делая своеобразные "скриншоты" изменений в файловой системе. Здесь интересно заметить, что многие современные бэкап-автоматы обладают подобным функционалом (им это нужно, чтобы реализовать простой алгоритм восстановления файловой системы "по состоянию на на момент n-го бэкапа" а заодно драматическим образом ускорить операции анализа данных), однако напрашивающаяся функция "быстрого обновления FULL за счёт старейшего INCR" нигде не рализована!
Да, предложенная идея сулит долгие ночи над программным кодом, но зато какие открываются перспективы, а? Мало того, что APBackUp рискует стать ПЕРВОЙ программой, реализующей ПОЛНОЦЕННЫЙ алгоритм "скользящего бэкапа", так ещё и функционал можно существенно расширить за счёт применения этих самых "скриншотов"! Например, появляется реальная возможность отслеживать копии файлов, разбросанные по разным местам хранилища, здорово экономя на объёмах и времени их архивирования/восстановления, сохраняя лишь первую копию такого файла, заменив остальные ссылками в этих самых "скриншотах"... Да, задача здорово превосходит функционал навороченного шедулера, коим на сегодня и является, на мой взгляд APBackUp... Однако, лиха беда начало! С нетерпением буду ждать Вашего ответа.... Удачи! С уважением, DenniOnLine.