"Актуализация" dump0

Обсуждение программы nnBackup

"Актуализация" dump0

Postby Deniska80 » Thu, 26 Nov 2015, 12:57

Здравствуйте
Хочется странного :) Может посоветуете что-то.

Скриптом бэкапятся данные с пользовательских машин, машин достаточно много.
До недавнего времени скрипт просто делал SYNC пользовательских данных, сохранение копий при этом обеспечивалось сменой каталогов, т.е. условно говоря, в понедельник все данные SYNCаются с каталогом \1\ на бэкап-сервере, во вторник - \2\ и т д.
Тут перерасход места налицо :(

Решил перейти на схему с DUMPами, но есть одна досадная мелочь - за рабочий день DUMP0 сделаться не успевает, просто не хватает времени.

В связи с этим вопрос, обозначенный в subj-е: можно ли каким то образом делать актуализацию DUMP0?

Т.е. DUMP0 каждый раз копирует ВСЕ файлы, чего я хотел бы избежать, достаточно скопировать только изменившиеся (фактически, сделать DUMP следующего уровня), и дампы следующего уровня делать уже исходя из даты этой синхронизации.

Пока придумал только делать SYNC с DUMP0, потом поправлять файл, где хранятся записи о времени последних дампов :(
Может есть более красивое решение?
Deniska80
 
Posts: 6
Joined: Mon, 22 Apr 2013, 17:13

Re: "Актуализация" dump0

Postby elos » Fri, 27 Nov 2015, 14:18

просто делал SYNC пользовательских данных, сохранение копий при этом обеспечивалось сменой каталогов,
По сути, этот ежедневный SYNC со сменой каталогов - это просто COPY (до первого повтора дня недели, затем реально SYNC относительно недельного периода).
Занимает место, но откатиться можно на любой день за прошедшую неделю. Оно же - суть DUMP0 (DUMP0 содержит в себе все файлы из источника данных).
досадная мелочь - за рабочий день DUMP0 сделаться не успевает, просто не хватает времени
Вот это уже интересно.
SYNC за день ты успевал сделать, а DUMP - нет (а DUMP0 - это твой же SYNC с архивированием)...
Подозрение, что что-то не так с архивированием...

Вопрос: какие объёмы обрабатываются, локально или по сетке, версия nnbackup?
И вообще - командную строку к осмотру (что рекомендуется при каждом задаваемом вопросе по скриптам).

Подозрение, что ты используешь -extzip для RAR, где можно налететь на грабли при неуказании ключом места временной папки.


А понимаем ли мы, что делаем?
Выражение про "актуализацию DUMP0" как-то некорректно звучит. Файл дампирования не правится, он создаётся заново согласно заданным ключам. Пользоваться только DUMP0 как-то нелогично получается при использовании дампирования, вся идея которого состоит в выстраивании схемы (последовательности) резервного копирования, которая уменьшит затраты времени на восстановление данных (особенно при больших объемах информации).

SYNC, философически рассуждая - ОДИН каталог, ежедневно подстаивающийся под источник. И нагадить этому каталогу в источнике можно раз и навсегда.
DUMP* - инкремент относительно некоей предыдущей копии при наличии полной версии источника, созданной DUMP0. А тут бяку сделать сложнее - откатиться можно до некоего предыдущего момента - для чего и создавалось...

И каждый раз надо понимать на какие допущения и ограничения ты идёшь...
elos
 
Posts: 665
Joined: Tue, 25 Apr 2006, 11:15

Re: "Актуализация" dump0

Postby Deniska80 » Mon, 30 Nov 2015, 11:53

elos wrote:
досадная мелочь - за рабочий день DUMP0 сделаться не успевает, просто не хватает времени
Вот это уже интересно.
SYNC за день ты успевал сделать, а DUMP - нет (а DUMP0 - это твой же SYNC с архивированием)...
Подозрение, что что-то не так с архивированием...


Нет, архивацию я не делаю вообще, т.е. -nozip использую.
Все верно - за 1 рабочий день SYNC тоже не успевал сделаться, конечно. Но на вторую-третью неделю - уже все ок.
Т.е. условно говоря, в первый понедельник успевал слить инфу с первых 50 компов, во второй - успевал посинкать первые 50 компов и слить с оставшихся 30. Ну а на третий понедельник SYNC успевает сделать на всех 80 .


Вопрос: какие объёмы обрабатываются, локально или по сетке, версия nnbackup?

Льется по сетке, объемы - порядка 100Гб за DUMP0, тут и в сетку упирается, конечно.
Версия 3.01 RC8 Build 137

И вообще - командную строку к осмотру (что рекомендуется при каждом задаваемом вопросе по скриптам).


Код запуска дампа такой
Code: Select all
nnbackup.exe dump 0 -nozip -tc -v -c -ci -i \\comp1\c$\Users -o Q:\DUMP\comp1 -log Q:\DOCBACKUP\logs\comp1.log -ll 9 -m  -s -p -p1


А понимаем ли мы, что делаем?
Выражение про "актуализацию DUMP0" как-то некорректно звучит. Файл дампирования не правится, он создаётся заново согласно заданным ключам. Пользоваться только DUMP0 как-то нелогично


Идея такая - в понедельник делать DUMP0, вт-пт - только DUMP1.2.3.4
Но, беда в том, что DUMP0 сделать не успевается :) ПОэтому идея такая была - в пн-к делаем SYNC на DUMP0 = SYNC успевает пройти, т.к. копирует только изменившиеся с последнего DUMP0 файлы, и обзываем это новым DUMP0, остальную неделю пляшем уже от него :)

SYNC, философически рассуждая - ОДИН каталог, ежедневно подстаивающийся под источник. И нагадить этому каталогу в источнике можно раз и навсегда.
DUMP* - инкремент относительно некоей предыдущей копии при наличии полной версии источника, созданной DUMP0. А тут бяку сделать сложнее - откатиться можно до некоего предыдущего момента - для чего и создавалось...
И каждый раз надо понимать на какие допущения и ограничения ты идёшь...


Да, понимание и осознание этого есть ):
Deniska80
 
Posts: 6
Joined: Mon, 22 Apr 2013, 17:13

Re: "Актуализация" dump0

Postby elos » Mon, 30 Nov 2015, 21:10

Прежде чем разродиться мыслёй - несколько вопросов с рассуждениями.

DUMP0 по 100Гб - это со всех машин или с одной? Если со всех - ладно, но если с одной, то куда ты льешь (просто интересно конфигурация хранилища - набор винтов или RAID)?

Все 80 компов постоянно включены? Дамп делает одна единственная машина последовательно? Дамп ложится на себя локально или ещё куда на сторону? Или можно распределить по времени и по машинам (сегментарно) выполнение дампирования/синхронизации и потом этими же машинами выполнить слив результата на хранилище?.. Машина, запускающая nnbackup, надесь, не самая слабая, как иногда бывает?

Кстати, последняя (у меня) версия nnBackup - V 3.02b3 Build 147. Может она чем поможет. И почему бы не попробовать архивы с внешним архиватором?

В ключе -m маска преднамеренно опущена? Иначе зачем этот ключ? Если маска была, то, если не секрет, какая? И что, даже с ней сотня гиг получается?
Что ж там из папки Users такого лить надо? Может можно умерить аппетиты на всю папку, а лить что-то более конкретное? А то у меня сама папка занимает примерно 7 гиг, а папка пользователя внутри - 3 гига. Бекапить документы? А важность этих документов требует такого подхода?

Если бояться потери документов по вине пользователя и стараться бекапить, то я бы организовал это локально на каждой машине. Есть некая стандартная консольная команда работы с разделами, позволяющая размонтировать/монтировать разделы диска. В нужное время (при отсутствии пользователя) подмонтировал скрытый раздел (винт, дополнительный, естественно), слил инфу, размонтировал (ну и меняй их раз в пару лет, если финансы позволяют, или по мере потерь...). Упасть ведь может не только сама машина пользователя, но и хранилище...
Да я ещё для восстановления системного раздела без лишних дум сразу после установки винды папки пользователя переназначаю на другой раздел.

Идея такая - в понедельник делать DUMP0, вт-пт - только DUMP1.2.3.4
Таким макаром тебе придётся последовательно накатывать все эти дампы на нулевой. Перечитай help - там пример описан минимизации количества накатов. Вся идея дампов - минимизировать время восстановления состояния файлов с минимальным расхождением по структуре с состоянием на момент потери с периодическим таки изготовлением DUMP0. Коряво как-то сформулировал, но как смог.

________________________________________________________________________
В принципе я уже "разродился" - я бы "распараллелил" задачу и потом слил в кучу, поиграв временем выполнения бекапа.
elos
 
Posts: 665
Joined: Tue, 25 Apr 2006, 11:15

Re: "Актуализация" dump0

Postby Deniska80 » Wed, 02 Dec 2015, 09:16

DUMP0 по 100Гб - это со всех машин или с одной? Если со всех - ладно, но если с одной, то куда ты льешь (просто интересно конфигурация хранилища - набор винтов или RAID)?

В данном конкретном случае - 100Гб примерно, это DUMP0 уровня всех машин, и льется все на дешевенький RAID10 из SATAшных дисков.

Все 80 компов постоянно включены? Дамп делает одна единственная машина последовательно? Дамп ложится на себя локально или ещё куда на сторону?

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

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

Или можно распределить по времени и по машинам (сегментарно) выполнение дампирования/синхронизации и потом этими же машинами выполнить слив результата на хранилище?.. Машина, запускающая nnbackup, надесь, не самая слабая, как иногда бывает?

Дело в том, что выбранная схема используется из-за своей простоты.

Если не взлетит, тогда я просто разверну backup решение другого уровня, с блэкджеком и остальным :) Просто хотелось обойтись nnbackup

Кстати, последняя (у меня) версия nnBackup - V 3.02b3 Build 147. Может она чем поможет. И почему бы не попробовать архивы с внешним архиватором?

Да, спасибо, обновлю, но вряд ли она скорость увеличит - тут все в сеть упирается, в самой программе ошибок нет.
А если архивировать внешним архиватором, то, конечно, время выполнения только увеличится.

В ключе -m маска преднамеренно опущена? Иначе зачем этот ключ? Если маска была, то, если не секрет, какая? И что, даже с ней сотня гиг получается?

Да, прошу прощения, неверно скопипастилось. На самом деле там вырезаны 2 маски - dx и mx, таким образом, что бэкапится только содержимое рабочих столов и документов пользователей.

Что ж там из папки Users такого лить надо? Может можно умерить аппетиты на всю папку, а лить что-то более конкретное? А то у меня сама папка занимает примерно 7 гиг, а папка пользователя внутри - 3 гига. Бекапить документы? А важность этих документов требует такого подхода?

Ну да, папка пользователя 3 гига. На машине может быть штук 5 пользователей, 80 машин - под 100Гб и выходит.

Если бояться потери документов по вине пользователя и стараться бекапить, то я бы организовал это локально на каждой машине. Есть некая стандартная консольная команда работы с разделами, позволяющая размонтировать/монтировать разделы диска. В нужное время (при отсутствии пользователя) подмонтировал скрытый раздел (винт, дополнительный, естественно), слил инфу, размонтировал (ну и меняй их раз в пару лет, если финансы позволяют, или по мере потерь...). Упасть ведь может не только сама машина пользователя, но и хранилище...
Да я ещё для восстановления системного раздела без лишних дум сразу после установки винды папки пользователя переназначаю на другой раздел.

Да, другие варианты выполнения, конечно есть, не спорю, и их много. Предложенный вами тоже не исключается.

В принципе я уже "разродился" - я бы "распараллелил" задачу и потом слил в кучу, поиграв временем выполнения бекапа.

Большое спасибо за уделенное время.
Я изначально, конечно, понимал, что хочется странного и нестандартного :) Тогда уж проще перейти (вернуться) на схему с SYNC в 5 разных каталогов - по дню недели.
Deniska80
 
Posts: 6
Joined: Mon, 22 Apr 2013, 17:13


Return to nnBackup forum (Russian)

Who is online

Users browsing this forum: No registered users and 3 guests