[gentoo-user-ru] Incremental backup system

[gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Приветствую.

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

Имеется несколько десятков файлов по 2-4 гигабайта. Изменений за день
не много. Использовать rsync для вычисления не годится - слишком много
требуется ресурсов и большое по времени ограничение на запись в файл.
В идеале видится патч для iNotify который вместе с событием об
изменении файла передавал смещение и размер изменившихся блоков. Некий
демон ведет журнал изменившихся блоков и по требованию передает их на
удаленный хост. Программа на удаленном хосте восстанавливает исходный
файл.

Существует ли что-то подобное в природе или придется писать самому?


-- 
Sergey

Re: [gentoo-user-ru] Incremental backup system

[John Brezerk]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>

> Приветствую.
>
> Необходима бэкап система которая могла бы записывать изменения в файле
> в отдельный файл, потом передавать эти изменения на другой хост и там
> собирать исходный файл.
>
> Имеется несколько десятков файлов по 2-4 гигабайта. Изменений за день
> не много. Использовать rsync для вычисления не годится - слишком много
> требуется ресурсов и большое по времени ограничение на запись в файл.
> В идеале видится патч для iNotify который вместе с событием об
> изменении файла передавал смещение и размер изменившихся блоков. Некий
> демон ведет журнал изменившихся блоков и по требованию передает их на
> удаленный хост. Программа на удаленном хосте восстанавливает исходный
> файл.
>
> Существует ли что-то подобное в природе или придется писать самому?
>
>
> --
> Sergey
>
>
>
Не претендую на истинность, но rsyncу можно сказать, чтобы он не проверял
хеши файлов (что бесспорно очень долго), а просто сравнивать дату изменения
файлов, и копировать тоько новый данные.

-- 
Regards,
Malakhov Alexey
OpenXlout, q4wine (  http://q4wine.brezblock.org.ua/  ) main developer.
BrezBlock ( http://brezblock.org.ua ) maintainer
e-mail: brezerk@gmail.com
web: http://brezblock.org.ua
BrezBlock, Kiev, Ukraine

[-- Attachment #2: Type: text/html, Size: 1785 bytes --]

Re[2]: [gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Wednesday, August 12, 2009, 2:06:35 PM, John wrote:

> 2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>
> Приветствую.

> Необходима бэкап система которая могла бы записывать изменения в файле
> в отдельный файл, потом передавать эти изменения на другой хост и там
> собирать исходный файл.

> Имеется несколько десятков файлов по 2-4 гигабайта. Изменений за день
> не много. Использовать rsync для вычисления не годится - слишком много
> требуется ресурсов и большое по времени ограничение на запись в файл.
> В идеале видится патч для iNotify который вместе с событием об
> изменении файла передавал смещение и размер изменившихся блоков. Некий
> демон ведет журнал изменившихся блоков и по требованию передает их на
> удаленный хост. Программа на удаленном хосте восстанавливает исходный
> файл.

> Существует ли что-то подобное в природе или придется писать самому?


> --
> Sergey


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

Да, можно такое сделать. Но если меняется в файле хоть 10 байт, то
придется передавать все 2Г на удаленный хост. Это ни есть хорошо и как
раз этого стараюсь избежать.


-- 
Sergey

Re: [gentoo-user-ru] Incremental backup system

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Wed, 12 Aug 2009 14:12:36 +0300
"Sergey A. Kobzar" <sergey.kobzar@mail.ru> wrote:

> > Не претендую на истинность, но rsyncу можно сказать, чтобы он не
> > проверял хеши файлов (что бесспорно очень долго), а просто
> > сравнивать дату изменения файлов, и копировать тоько новый данные.
> 
> Да, можно такое сделать. Но если меняется в файле хоть 10 байт, то
> придется передавать все 2Г на удаленный хост. Это ни есть хорошо и как
> раз этого стараюсь избежать.

С параметром --inplace вроде бы man rsync говорит о delta-transfer
алгоритме, хотя сам данный параметр не применял.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re[2]: [gentoo-user-ru] Incremental backup system

[John Brezerk]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>

> Wednesday, August 12, 2009, 2:06:35 PM, John wrote:
>
> > 2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>
> > Приветствую.
>
> > Необходима бэкап система которая могла бы записывать изменения в файле
> > в отдельный файл, потом передавать эти изменения на другой хост и там
> > собирать исходный файл.
>
> > Имеется несколько десятков файлов по 2-4 гигабайта. Изменений за день
> > не много. Использовать rsync для вычисления не годится - слишком много
> > требуется ресурсов и большое по времени ограничение на запись в файл.
> > В идеале видится патч для iNotify который вместе с событием об
> > изменении файла передавал смещение и размер изменившихся блоков. Некий
> > демон ведет журнал изменившихся блоков и по требованию передает их на
> > удаленный хост. Программа на удаленном хосте восстанавливает исходный
> > файл.
>
> > Существует ли что-то подобное в природе или придется писать самому?
>
>
> > --
> > Sergey
>
>
> > Не претендую на истинность, но rsyncу можно сказать, чтобы он не
> > проверял хеши файлов (что бесспорно очень долго), а просто
> > сравнивать дату изменения файлов, и копировать тоько новый данные.
>
> Да, можно такое сделать. Но если меняется в файле хоть 10 байт, то
> придется передавать все 2Г на удаленный хост. Это ни есть хорошо и как
> раз этого стараюсь избежать.
>
>
> --
> Sergey
>
>
>
Топикстеру на заметку:

DESCRIPTION
  Rsync is a fast and extraordinarily ........... It is famous for its
delta-transfer algorithm, which reduces the amount of data sent
  over the network by sending only the differences between the source files
and the existing files in the destination....

Сам я правда delta-transfer не проверял :)




-- 
Regards,
Malakhov Alexey
OpenXlout, q4wine (  http://q4wine.brezblock.org.ua/  ) main developer.
BrezBlock ( http://brezblock.org.ua ) maintainer
e-mail: brezerk@gmail.com
web: http://brezblock.org.ua
BrezBlock, Kiev, Ukraine

[-- Attachment #2: Type: text/html, Size: 2765 bytes --]

Re[4]: [gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Wednesday, August 12, 2009, 2:19:09 PM, John wrote:

> 2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>
> Wednesday, August 12, 2009, 2:06:35 PM, John wrote:

>> 2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>
>> Приветствую.

>> Необходима бэкап система которая могла бы записывать изменения в файле
>> в отдельный файл, потом передавать эти изменения на другой хост и там
>> собирать исходный файл.

>> Имеется несколько десятков файлов по 2-4 гигабайта. Изменений за день
>> не много. Использовать rsync для вычисления не годится - слишком много
>> требуется ресурсов и большое по времени ограничение на запись в файл.
>> В идеале видится патч для iNotify который вместе с событием об
>> изменении файла передавал смещение и размер изменившихся блоков. Некий
>> демон ведет журнал изменившихся блоков и по требованию передает их на
>> удаленный хост. Программа на удаленном хосте восстанавливает исходный
>> файл.

>> Существует ли что-то подобное в природе или придется писать самому?


>> --
>> Sergey


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

> Да, можно такое сделать. Но если меняется в файле хоть 10 байт, то
> придется передавать все 2Г на удаленный хост. Это ни есть хорошо и как
> раз этого стараюсь избежать.


> --
> Sergey




> Топикстеру на заметку:

> DESCRIPTION
>   Rsync is a fast and extraordinarily ........... It is famous for
> its delta-transfer algorithm, which reduces the amount of data sent
>   over the network by sending only the differences between the
> source files and the existing files in the destination....

> Сам я правда delta-transfer не проверял  

В общем конкретный случай:
есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
все это время виртуальная машина должна быть остановлена. Не годится
такое решение...


-- 
Sergey

Re: Re[4]: [gentoo-user-ru] Incremental backup system

[John Brezerk]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]

2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>

> Wednesday, August 12, 2009, 2:19:09 PM, John wrote:
>
> > 2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>
> > Wednesday, August 12, 2009, 2:06:35 PM, John wrote:
>
> >> 2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>
> >> Приветствую.
>
> >> Необходима бэкап система которая могла бы записывать изменения в файле
> >> в отдельный файл, потом передавать эти изменения на другой хост и там
> >> собирать исходный файл.
>
> >> Имеется несколько десятков файлов по 2-4 гигабайта. Изменений за день
> >> не много. Использовать rsync для вычисления не годится - слишком много
> >> требуется ресурсов и большое по времени ограничение на запись в файл.
> >> В идеале видится патч для iNotify который вместе с событием об
> >> изменении файла передавал смещение и размер изменившихся блоков. Некий
> >> демон ведет журнал изменившихся блоков и по требованию передает их на
> >> удаленный хост. Программа на удаленном хосте восстанавливает исходный
> >> файл.
>
> >> Существует ли что-то подобное в природе или придется писать самому?
>
>
> >> --
> >> Sergey
>
>
> >> Не претендую на истинность, но rsyncу можно сказать, чтобы он не
> >> проверял хеши файлов (что бесспорно очень долго), а просто
> >> сравнивать дату изменения файлов, и копировать тоько новый данные.
>
> > Да, можно такое сделать. Но если меняется в файле хоть 10 байт, то
> > придется передавать все 2Г на удаленный хост. Это ни есть хорошо и как
> > раз этого стараюсь избежать.
>
>
> > --
> > Sergey
>
>
>
>
> > Топикстеру на заметку:
>
> > DESCRIPTION
> >   Rsync is a fast and extraordinarily ........... It is famous for
> > its delta-transfer algorithm, which reduces the amount of data sent
> >   over the network by sending only the differences between the
> > source files and the existing files in the destination....
>
> > Сам я правда delta-transfer не проверял
>
> В общем конкретный случай:
> есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
> виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
> вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
> все это время виртуальная машина должна быть остановлена. Не годится
> такое решение...
>
>
> --
> Sergey
>
>
>
Без обид. Где вас таких учат? :)

Есть lvm с _заморозкой_ текущего состояния данных. (В двух словах: это
специально чтобы не останавливать сервера для бекапа. т.к. это почти копия
данных. See lvm manpages for details.)

Алгоритм:
1. делаем заморозку средствами lvm.
2. далее эти данные передаем дельтой с rsync'ом.
3. сносим заморозку.

При этом сервера как работали так и будут работать дальше. ниочем не
подозревая.
Конечно для этого нужен _грамотный_ изначальный подход к установке базовой
системы.

-- 
Regards,
Malakhov Alexey
OpenXlout, q4wine (  http://q4wine.brezblock.org.ua/  ) main developer.
BrezBlock ( http://brezblock.org.ua ) maintainer
e-mail: brezerk@gmail.com
web: http://brezblock.org.ua
BrezBlock, Kiev, Ukraine

[-- Attachment #2: Type: text/html, Size: 4022 bytes --]

Re: [gentoo-user-ru] Incremental backup system

[spirit]

Sergey A. Kobzar пишет:
> 
> В общем конкретный случай:
> есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
> виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
> вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
> все это время виртуальная машина должна быть остановлена. Не годится
> такое решение...
> 
> 

размещаете виртуальные диски на LVM разделы,
потом совмещаете слепки/снапшоты LVM и rsync..
в этом случае тормозить VM не надо.

Re[6]: [gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Wednesday, August 12, 2009, 2:47:00 PM, John wrote:

> Без обид. Где вас таких учат?

Google в основном.


> Есть lvm с _заморозкой_ текущего состояния данных. (В двух словах:
> это специально чтобы не останавливать сервера для бекапа. т.к. это
> почти копия данных. See lvm manpages for details.)

Имеется ввиду снэпшоты на уровне ФС?


> Алгоритм:
> 1. делаем заморозку средствами lvm.
> 2. далее эти данные передаем дельтой с rsync'ом.
> 3. сносим заморозку.

"заморозка" == снэпшот?

Да, это как вариант...


> При этом сервера как работали так и будут работать дальше. ниочем не подозревая.
> Конечно для этого нужен _грамотный_ изначальный подход к установке базовой системы.

_грамотный_ - имеется ввиду создание LVM volume? :)


-- 
Sergey

Re[2]: [gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Wednesday, August 12, 2009, 2:47:41 PM, spirit wrote:

> Sergey A. Kobzar пишет:
>> 
>> В общем конкретный случай:
>> есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
>> виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
>> вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
>> все это время виртуальная машина должна быть остановлена. Не годится
>> такое решение...
>> 
>> 

> размещаете виртуальные диски на LVM разделы,
> потом совмещаете слепки/снапшоты LVM и rsync..
> в этом случае тормозить VM не надо.

Да, это уже как вариант...

А насколько падает перфоманс на LVM разделе по сравнению с обычным
разделом?


-- 
Sergey

Re: Re[6]: [gentoo-user-ru] Incremental backup system

[John Brezerk]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>

> Wednesday, August 12, 2009, 2:47:00 PM, John wrote:
>
> > Без обид. Где вас таких учат?
>
> Google в основном.


Тогда вам будет полезна следующая ссылка: http://xgu.ru/wiki/LVM
Для  начала самое оно.


>
>
> > Есть lvm с _заморозкой_ текущего состояния данных. (В двух словах:
> > это специально чтобы не останавливать сервера для бекапа. т.к. это
> > почти копия данных. See lvm manpages for details.)
>
> Имеется ввиду снэпшоты на уровне ФС?
>
>
> > Алгоритм:
> > 1. делаем заморозку средствами lvm.
> > 2. далее эти данные передаем дельтой с rsync'ом.
> > 3. сносим заморозку.
>
> "заморозка" == снэпшот?
>
> Да, это как вариант...
>
Он самый :)


>
> > При этом сервера как работали так и будут работать дальше. ниочем не
> подозревая.
> > Конечно для этого нужен _грамотный_ изначальный подход к установке
> базовой системы.
>
> _грамотный_ - имеется ввиду создание LVM volume? :)
>

Ну да. Отведение места под lvm раздел + место под сам снапшот.

-- 
Regards,
Malakhov Alexey
OpenXlout, q4wine (  http://q4wine.brezblock.org.ua/  ) main developer.
BrezBlock ( http://brezblock.org.ua ) maintainer
e-mail: brezerk@gmail.com
web: http://brezblock.org.ua
BrezBlock, Kiev, Ukraine

[-- Attachment #2: Type: text/html, Size: 2222 bytes --]

Re: Re[2]: [gentoo-user-ru] Incremental backup system

[John Brezerk]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>

> Wednesday, August 12, 2009, 2:47:41 PM, spirit wrote:
>
> > Sergey A. Kobzar пишет:
> >>
> >> В общем конкретный случай:
> >> есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
> >> виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
> >> вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
> >> все это время виртуальная машина должна быть остановлена. Не годится
> >> такое решение...
> >>
> >>
>
> > размещаете виртуальные диски на LVM разделы,
> > потом совмещаете слепки/снапшоты LVM и rsync..
> > в этом случае тормозить VM не надо.
>
> Да, это уже как вариант...
>
> А насколько падает перфоманс на LVM разделе по сравнению с обычным
> разделом?
>
>
> --
> Sergey
>
>
>
Все зависит от конфигурации. В обычных ситуациях разницы не заметно.

-- 
Regards,
Malakhov Alexey
OpenXlout, q4wine (  http://q4wine.brezblock.org.ua/  ) main developer.
BrezBlock ( http://brezblock.org.ua ) maintainer
e-mail: brezerk@gmail.com
web: http://brezblock.org.ua
BrezBlock, Kiev, Ukraine

[-- Attachment #2: Type: text/html, Size: 1702 bytes --]

Re: Re[4]: [gentoo-user-ru] Incremental backup system

[Azamat Hackimov]

> В общем конкретный случай:
> есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
> виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
> вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
> все это время виртуальная машина должна быть остановлена. Не годится
> такое решение...

Тут надо смотреть сервисы репликации, которые предоставляются самим
сервером VMWare. Они определенно есть, просто надо поискать
информацию. В идеальном случае - рабочие копии образов машин
синхронизируются в реальном времени между двумя серверами виртуальных
машин.

-- 
From Siberia with Love!

Re[4]: [gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Wednesday, August 12, 2009, 3:03:14 PM, John wrote:



> 2009/8/12 Sergey A. Kobzar <sergey.kobzar@mail.ru>
> Wednesday, August 12, 2009, 2:47:41 PM, spirit wrote:

>> Sergey A. Kobzar пишет:
>>>
>>> В общем конкретный случай:
>>> есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
>>> виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
>>> вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
>>> все это время виртуальная машина должна быть остановлена. Не годится
>>> такое решение...
>>>
>>>

>> размещаете виртуальные диски на LVM разделы,
>> потом совмещаете слепки/снапшоты LVM и rsync..
>> в этом случае тормозить VM не надо.


> Да, это уже как вариант...

> А насколько падает перфоманс на LVM разделе по сравнению с обычным
> разделом?


> --
> Sergey




> Все зависит от конфигурации. В обычных ситуациях разницы не заметно.


Спасибо. Надо будет потестить. Идея неплохая :)

Сам как-то недодумался %/...


-- 
Sergey

Re[6]: [gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Wednesday, August 12, 2009, 3:08:55 PM, Azamat wrote:

>> В общем конкретный случай:
>> есть VMware Virtual Machine. Изменения пишутся в vmdk файлы. Размер
>> виртуальной машины 60-120Г. Сколько нужно времени rsync чтобы
>> вычислить дэльту и передать ее на удаленный хост даже по 1Г сети? И
>> все это время виртуальная машина должна быть остановлена. Не годится
>> такое решение...

> Тут надо смотреть сервисы репликации, которые предоставляются самим
> сервером VMWare. Они определенно есть, просто надо поискать
> информацию. В идеальном случае - рабочие копии образов машин
> синхронизируются в реальном времени между двумя серверами виртуальных
> машин.

Нет, риалтам синхронизация не нужна. Сейчас у меня риалтайм
синхронизация работает на основе DRBD партишина, но:
1. требуется отдельный партишн что создает доп. неудобства.
2. хорошо проседает перфоманс
3. плохо обстоят дела с поддержкой ядер последних версий
4. требуются доп. винты и место в стойке, а это доп. деньги на
   колокейшене

Бэкап решения от самой VMware Inc не нравятся их дороговизной и
завышенными требованиями к харду.



-- 
Sergey

Re[4]: [gentoo-user-ru] Incremental backup system

[Sergey A. Kobzar]

Wednesday, August 12, 2009, 3:03:14 PM, John wrote:

> А насколько падает перфоманс на LVM разделе по сравнению с обычным
> разделом?

> --
> Sergey



> Все зависит от конфигурации. В обычных ситуациях разницы не заметно.

Немного погуглил и нашел что производительность LVM в snapshot mode
падает в 3-6 раз:

http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-performance-in-snapshot-mode/

So Creating LVM snapshot indeed could cause tremendous overhead - in
the benchmarks I've done it is ranging from 3x to 6x.


Не вариант...


-- 
Sergey