ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Алгоритм "Ханойские Башни" при использовании dump/restore
3 сообщений из 3, страница 1 из 1
Алгоритм "Ханойские Башни" при использовании dump/restore
    #33764287
Pavel Kilevatyh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel Kilevatyh
Участник
Доброго дня.
Никак не могу разобраться с пакетом для инкрементального резервного копирования dump/restore. Точнее как правильно использовать эти уровни копирования. Привожу цитату из man:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
  In the event of a catastrophic disk event, the time required to restore all the necessary 
backup tapes or files to disk can  be  kept  to a minimum by staggering the incremental 
dumps. An efficient method of staggering incremental dumps to  minimize the number of 
tapes follows:

 --     Always start with a level 0 backup, for example:
                     /sbin/dump -0u -f /dev/st0 /usr/src

  This should be done at set intervals, say once a month or once every two months, and 
on a  set  of  fresh  tapes  that is saved forever.

       --     After  a level 0, dumps of active file systems are taken on a daily basis, using
a modified Tower of Hanoi algorithm, with this sequence of dump levels:
                      3   2   5   4   7   6   9   8   9   9  ...

For the daily dumps, it should be possible to use a fixed number of tapes for each day,
used on a weekly  basis. Each  week,  a  level   1  dump is taken, and the daily Hanoi 
sequence repeats beginning with  3 . For weekly dumps,  another fixed set of tapes per 
dumped file system is used, also on a cyclical basis.

After several months or so, the daily and weekly tapes should get rotated out of the 
dump cycle and fresh tapes brought in.

Коллега высказал разумное предположение, что каждый месяц или каждые два месяца нужно делать бакап 0 уровня, после чего по 3,2,5,4,7,6,8 для Пн, Вт, Ср, Чт, Пт, Сб, Вс; после чего недельный бакап 1 уровня и с начала. Причем, если я правильно понял, то 1 уровень можно делать и раз в две недели, тогда уровни копирования должны быть такими:
3,2,5,4,7,6,8 для первой недели,
9,9,9,9,9,9,9 для второй недели.

Соответственно, восстановление проводить в таком порядке:
0 - бакап последнего месяца
1 - последний недельный бакап
3,2,..... до момента на который желательно восстановить ФС.

Мы правильно поняли мануал ?
...
Рейтинг: 0 / 0
31.05.2006, 17:57:56
| Ответить | Цитировать | Написать  
Алгоритм "Ханойские Башни" при использовании dump/restore
    #33764299
Фотография lissyara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lissyara
Участник
возьми да попробуй.
всё равно в бой без обкатки не запустишь.
тестовая машина - неделя времени и всё.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
31.05.2006, 18:00:03
| Ответить | Цитировать | Написать  
Алгоритм "Ханойские Башни" при использовании dump/restore
    #33765161
Pavel Kilevatyh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel Kilevatyh
Участник
Возможно кому-то будет интересно услышать чем закончились мои опыты.
Изначально стояла задача резервного копирования базовой ФС, причем учитывая размер корневого каталога, это не комфортно делать с помощью tar.
Если отбросить каталоги /tmp и /var, то можно сказать, что ФС изменяется очень редко, соответственно инкрементальные бакапы должны быть очень малыми и делать их можно относительно редко. Положим раз в неделю. Все равно в случае краха RAID контроллера и обоих дисков (RAID level 1), восстановление из резерва будет быстрее чем установка системы.
И удовлетворительна даже на неделю назад. Это исходя из того, что БД и документы пользователей резервируются отдельно. Именно поэтому я вспомнил за пакет утилит для инкрементального резервного копирования dump/restore. Этот пакет умеет работать с ext2 и ext3.
Как видно из моего первого поста, документация оказалась далеко не исчерпывающей, подразумевалось что человек использующий пакет понимает что такое уровни резервной копии и как их делать.
Сейчас я попытаюсь рассказать что это в двух словах. Для тех кто хочет поэксперементировать самостоятельно выкладываю два скрипта.
back.sh :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
#!/bin/sh
# Скрипт-оболочка, управляющий резервным копированием и 
# нумерацией дисков

change_data(){
    echo "Делаю изменения на ФС"
    curr_dir=`pwd`
    cd /mnt/play               # точка монтирования для тестовой ФС
    bash ./changes $ 1 
    sleep  2     
    cd $curr_dir
}

func_dump(){
    level=$ 1 
    volume=$ 2 
    dump  -u$level -j9 -f /opt/fs/bak/loop_$volume.img /dev/loop2  &>/dev/null
}

volume= 0 
for level in  0   3   7   9   9   1 ; do
    MSG="Резервная копия уровня $level, том номер $volume";
    echo $MSG
    change_data "состояние_перед_резервной_копией_уровня_$level,_том_номер_$volume";
    umount /mnt/play
    sleep  1 
    mount /dev/loop2 /mnt/play
    func_dump $level $volume
    volume=`expr $volume +  1 `
done
и changes :
Код: plaintext
1.
2.
3.
4.
5.
#!/bin/sh
CURR=`date +%Y-%m-%d[%H:%M:%S]`
echo $CURR > changeble_time
echo $CURR >> incremental_time
echo $ 1  >  updated_$CURR

Создал тестовую ФС (16Mb) с помощью:
Код: plaintext
1.
2.
3.
4.
dd if=/dev/null of=/opt/fs/play.img bs=1024K count=16K
losetup /dev/loop2 /opt/fs/play.img
mke2fs /dev/loop2
mount /dev/loop2 /mnt/play

Теперь выполняя скрипт back.sh и меняя в нем уровни архива, можно поглядеть как работает система. Уровни архива - список, передаваемый в for оператор.

Восстановление предварительно отформатированной тестовой ФС производится командами:
Код: plaintext
1.
2.
  cd /mnt/play
  restore rf /opt/fs/bak/loop_<нужный номер тома>.img

Теперь по поводу уровней.
Уровень 0 - полное резервное копирование ВСЕЙ файловой системы за исключением явно указаных номеров нодов (inode), посмотреть которые можно командой stat <имя файла>. Для подробной информации смотрите man dump. Предполагается, что копия с уровнем 0 делается ОЧЕНЬ редко. Положим раз в год.
Уровни 1-9 резервируют только изменения произошедшие между предыдущим уровнем существующего бакапа и текущего.

Это означает, что если я сделал бакапы уровней 0 1 2 3 4 5 6 7 8 9 1 2 1, то для восстановления последнего состояния системы мне надо поднять из резерва 0 и последний 1 уровень.
В случае такой расстановки бакапов 0 1 2 3 4 1 2 3 4, для восстановления нужно использовать 0 и вторую цепочку 1 2 3 4.

Вот теперь возникает вопрос, что это за алгоритм "Ханойские Башни" и как с его использованием можно сократить к минимуму кол-во необходимых томов с инкрементальными бакапами. Из описания в мане все еще не понятно.
...
Рейтинг: 0 / 0
01.06.2006, 10:40:24
| Ответить | Цитировать | Написать  
3 сообщений из 3, страница 1 из 1
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Алгоритм "Ханойские Башни" при использовании dump/restore
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=25&msg=33764287&tid=1489435]:
 0ms
get settings:
 7ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 42ms
get topic data:
 6ms
get forum data:
 2ms
get page messages:
 26ms
get tp. blocked users:
 1ms
others: 204ms
total:  302ms
созд. / загр.: 302ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]