История изменений
Исправление DALDON, (текущая версия) :
Такс, я может тоже всячески погорячился. :) Но я не со зла, конечно. :)
Во-первых скажу, что я сам ухожу конечно от rdiff-backup, и буду пользоваться baculа, а значит я понимаю, все её достоинства. Тут спора нету, конечно. :)
Не требуется. В случае с Bacul'ой прошлая версия файла может лежать где-то на отключенном томе в сейфе в бункере за 300 километров, нужна только её контрольная сумма в базе Director'а.
Я имел ввиду, что потребуется, в случае восстановления, конечно. Спасибо за уточнение, про контрольную сумму в director. Я не задумывался об том, как оно там хранится.
rdiff-backup не попросит дать ему возможность читать то что я записал в понедельник и уже унёс архив и запер под замок, чтобы посчитать изменения в файлах?
Попросит, конечно, но только вчерашний день. Но там будет мало данных. Но в целом, да попросит.
Что это за бред вы сейчас написали? 2 копии в Bacul'е весят как 2 копии, но никак не 3
Такс... Представим ситуацию: пусть bacula записывает в один том весь job. Пишем в том А... Записали. Пишем в том Б - записали... - Вот уже имеется всего две копии. На следующий раз: пишем снова в том А - мы ведь по кругу ходим? Всё верно? Мы ведь следуем Вашей логике, что (2 копии в Bacul'е весят как 2 копии). И тут у нас случился обрыв нашего задания (не важно, сеть там отвалилась или чего-то ещё приключилось), мы имеем то, что: том А уже вычищен из каталога, том А уже имеет часть данных перезаписанными. - И таким образом, у нас осталась всего одна резервная копия, в томе Б. Как-то так. Скажем так: шанс то, что оборвётся job длинною в 2тб, весьма велик. По сему (везде пишут), и я с этим согласен: что надо всё же иметь три тома. А, Б, В - если нам надо гарантированно иметь две копии наших данных.
У меня на позапрошлой работе была именно такая ситуация, и я не обосрался. Я по субботам делал Full, по ночам будних дней Incremental
Так минус такого подхода в том, что каждую неделю бессмысленный напряг клиента, и передача по сети одного и того же трафика, очень большого объёма. Какой в этом смысл? Если только фирма не настолько богата, что может себе позволить каждую неделю иметь новые носители для томов.
Что такое VirtualFullBackup?
http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html#SECTIO... как-то так. Это чтобы не делать вот такого:
Я по субботам делал Full
Ещё раз, полная копия данных весит как полная копия данных независимо от того используется ли Bacula, tar или rdiff-backup. Магии не существует. Инкрементальная копия может весить меньше чем у Bacul'ы, но это добавляет требований к доступности вчерашних резервных копий.
Всё так, если делать backup qcow2 образов, то у bacula вообще не будет никакой разницы, между Full и Incremental, а вот это уже не очень хорошо.
Всё это нормально сохранялось на двухтерабайтные НЖМД, которые я старался менять по кругу, но часть начальник увозил к себе домой и забывал вовремя привезти обратно, так что порядок замены нарушался, но это не вызывало сбоев.
Да я не вижу смысла заниматься тем, что куда-то, чего-то увозить в какие-то сейфы... А вообще, может покритикуете мой паттерн:
Я для хранения томов впиливаю:
md1 + md1 + md1, поверх этого: lvm. И гоняю по кругу vol. Таким образом, я получаю один, большой раздел, и мне не страшен отказ одного диска, и при случае даже двух дисков (если откажут, в разных md). Вроде всё годно, в целом. Мне очень хотелось бы тупо хранить разные job, на разных дисках, но мне кажется, что есть опасность того, что я могу не подняться с какого-то из job, если у меня случится отказ одного из НЖМД. По сему, приходится выплачивать n2, от полезного объёма хранилища.
Исправление DALDON, :
Такс, я может тоже всячески погорячился. :) Но я не со зла, конечно. :)
Во-первых скажу, что я сам ухожу конечно от rdiff-backup, и буду пользоваться baculа, а значит я понимаю, все её достоинства. Тут спора нету, конечно. :)
Не требуется. В случае с Bacul'ой прошлая версия файла может лежать где-то на отключенном томе в сейфе в бункере за 300 километров, нужна только её контрольная сумма в базе Director'а.
Я имел ввиду, что потребуется, в случае восстановления, конечно. Спасибо за уточнение, про контрольную сумму в director. Я не задумывался об том, как оно там хранится.
rdiff-backup не попросит дать ему возможность читать то что я записал в понедельник и уже унёс архив и запер под замок, чтобы посчитать изменения в файлах?
Попросит, конечно, но только вчерашний день. Но там будет мало данных. Но в целом, да попросит.
Что это за бред вы сейчас написали? 2 копии в Bacul'е весят как 2 копии, но никак не 3
Такс... Представим ситуацию: пусть bacula записывает в один том весь job. Пишем в том А... Записали. Пишем в том Б - записали... - Вот уже имеется всего две копии. На следующий раз: пишем снова в том А - мы ведь по кругу ходим? Всё верно? Мы ведь следуем Вашей логике, что (2 копии в Bacul'е весят как 2 копии). И тут у нас случился обрыв нашего задания (не важно, сеть там отвалилась или чего-то ещё приключилось), мы имеем то, что: том А уже вычищен из каталога, том А уже имеет часть данных перезаписанными. - И таким образом, у нас осталась всего одна резервная копия, в томе Б. Как-то так. Скажем так: шанс то, что оборвётся job длинною в 2тб, весьма велик. По сему (везде пишут), и я с этим согласен: что надо всё же иметь три тома. А, Б, В - если нам надо гарантированно иметь две копии наших данных.
У меня на позапрошлой работе была именно такая ситуация, и я не обосрался. Я по субботам делал Full, по ночам будних дней Incremental
Так минус такого подхода в том, что каждую неделю бессмысленный напряг клиента, и передача по сети одного и того же трафика, очень большого объёма. Какой в этом смысл? Если только фирма не настолько богата, что может себе позволить каждую неделю иметь новые носители для томов.
Что такое VirtualFullBackup?
http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html#SECTIO... как-то так. Это чтобы не делать вот такого:
Я по субботам делал Full
Ещё раз, полная копия данных весит как полная копия данных независимо от того используется ли Bacula, tar или rdiff-backup. Магии не существует. Инкрементальная копия может весить меньше чем у Bacul'ы, но это добавляет требований к доступности вчерашних резервных копий.
Всё так, если делать backup qcow2 образов, то у bacula вообще не будет никакой разницы, между Full и Incremental, а вот это уже не очень хорошо.
Всё это нормально сохранялось на двухтерабайтные НЖМД, которые я старался менять по кругу, но часть начальник увозил к себе домой и забывал вовремя привезти обратно, так что порядок замены нарушался, но это не вызывало сбоев.
Да я не вижу смысла заниматься тем, что куда-то, чего-то увозить в какие-то сейфы... А вообще, может покритикуешь мой паттерн:
Я для хранения томов впиливаю:
md1 + md1 + md1, поверх этого: lvm. И гоняю по кругу vol. Таким образом, я получаю один, большой раздел, и мне не страшен отказ одного диска, и при случае даже двух дисков (если откажут, в разных md). Вроде всё годно, в целом. Мне очень хотелось бы тупо хранить разные job, на разных дисках, но мне кажется, что есть опасность того, что я могу не подняться с какого-то из job, если у меня случится отказ одного из НЖМД. По сему, приходится выплачивать n2, от полезного объёма хранилища.
Исходная версия DALDON, :
Такс, я может тоже всячески погорячился. :) Но я не со зла, конечно. :)
Во-первых скажу, что я сам ухожу конечно от rdiff-backup, и буду пользоваться baculа, а значит я понимаю, все её достоинства. Тут спора нету, конечно. :)
Не требуется. В случае с Bacul'ой прошлая версия файла может лежать где-то на отключенном томе в сейфе в бункере за 300 километров, нужна только её контрольная сумма в базе Director'а.
Я имел ввиду, что потребуется, в случае восстановления, конечно. Спасибо за уточнение, про контрольную сумму в director. Я не задумывался об том, как оно там хранится.
rdiff-backup не попросит дать ему возможность читать то что я записал в понедельник и уже унёс архив и запер под замок, чтобы посчитать изменения в файлах?
Попросит, конечно, но только вчерашний день. Но там будет мало данных. Но в целом, да попросит.
Что это за бред вы сейчас написали? 2 копии в Bacul'е весят как 2 копии, но никак не 3
Такс... Представим ситуацию: пусть bacula записывает в один том весь job. Пишем в том А... Записали. Пишем в том Б - записали... - Вот уже имеется всего две копии. На следующий раз: пишем снова в том А - мы ведь по кругу ходим? Всё верно? Мы ведь следуем Вашей логике, что (2 копии в Bacul'е весят как 2 копии). И тут у нас случился обрыв нашего задания (не важно, сеть там отвалилась или чего-то ещё приключилось), мы имеем то, что: том А уже вычищен из каталога, том А уже имеет часть данных перезаписанными. - И таким образом, у нас осталась всего одна резервная копия, в томе Б. Как-то так. Скажем так: шанс то, что оборвётся job длинною в 2тб, весьма велик. По сему (везде пишут), и я с этим согласен: что надо всё же иметь три тома. А, Б, В - если нам надо гарантированно иметь две копии наших данных.
У меня на позапрошлой работе была именно такая ситуация, и я не обосрался. Я по субботам делал Full, по ночам будних дней Incremental
Так минус такого подхода в том, что каждую неделю бессмысленный напряг клиента, и передача по сети одного и того же трафика, очень большого объёма. Какой в этом смысл? Если только фирма не настолько богата, что может себе позволить каждую неделю иметь новые носители для томов.
Что такое VirtualFullBackup?
http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html#SECTIO... как-то так. Это чтобы не делать вот такого:
Я по субботам делал Full
Ещё раз, полная копия данных весит как полная копия данных независимо от того используется ли Bacula, tar или rdiff-backup. Магии не существует. Инкрементальная копия может весить меньше чем у Bacul'ы, но это добавляет требований к доступности вчерашних резервных копий.
Всё так, если делать backup qcow2 образов, то у bacula вообще не будет никакой разницы, между Full и Incremental, а вот это уже не очень хорошо.
Всё это нормально сохранялось на двухтерабайтные НЖМД, которые я старался менять по кругу, но часть начальник увозил к себе домой и забывал вовремя привезти обратно, так что порядок замены нарушался, но это не вызывало сбоев.
Да я не вижу смысла заниматься тем, что куда-то, чего-то увозить в какие-то сейфы... А вообще, может покритикуешь мой паттерн:
Я для хранения томов впиливаю:
md1 + md1 + md1, поверх этого: lvm. И гоняю по кругу vol. Таким образом, я получаю один, большой раздел, и мне не страшен отказ одного диска, и при случае даже двух дисков (если откажут, в разных md). Вроде всё годно, в целом. Мне очень хотелось бы тупо хранить разные job, на разных дисках, но мне кажется, что есть опасность того, что я могу не подняться с какого-то из job, если у меня случится отказ одного из НЖМД.