Rozterki początującego

Witam wszystkich, jestem tu nowy.

Zaczynam dopiero przygodę z bacula.
Przeczytałem tutaj sporo artykułów więc coś tam już wiem
Mam nadzieję, że ktoś pomoże mi zrozumieć więcej :-)

1 .
Do tej pory zainstalowałem serwer w wersji 7.4.7, wstępnie skonfigurowałem i wykonałem testowy backup.
Backup wykonany został z serwera, na którym zainstalowałem klienta.
Backup zapisałem na taśmę LTO-6, (na urządzeniu hp ultrium 6250)

Backup zawierał 5Mln plików i 1TB danych.
Całość trwała ponad 13 godzin, co daje jakieś 23MB/s. (sieć 1Gb)
Pierwsze pytanie - czy to jest dobry wynik - bo spodziewałem się lepszego (100MB/s ??) ?

2.
Chciałbym upewnić się co do zasady tworzenia backup(ów).

Moim celem jest wykonanie na początek backupów z pięciu serwerów (klientów).
Cztery lokalizacje po około 200GB danych i jedna około 600GB razem około 1,5TB

Przy takim czasie jak wyliczyłem dla backupu testowego, pełny backup zajmie mi jakieś 15-16 godzin.
(nie próbowałem ustawiać jeszcze Spool Attributes)

Planowałem wykonywać plan backup w oparciu o tzw. advanced 5 day GFS (1 roczna retencja, 18 tasiemek)

Szczerze mówiąc nie wiem jak do tego podejść.

Do wyboru mam takie drogi:
Pierwsza - robić backup z klientów na dysk w storage i dopiero później na LTO
Druga - robić backup z klientów bezpośrednio na LTO
trzecia - robić backup dzienny z klientów na storage a tygodniowy i miesięczny na LTO
czwarta - inny??

Czy w przypadku gdy będę chciał robić backup z klientów bezpośrednio na LTO
muszę zdefiniować tyle job-ów, ile mam klientów i uwzględnić w harmonogramie uruchamianie job-ów z odpowiednim przesunięciem czasowym?
Co jeśli przewidzę zbyt krótki czas na wykonanie job-a?
Czy jeśli chcę wykorzystać jedną taśmę na backupy dniowe w tygodniu, muszę uwzględnić, że w ciągu jednego dnia wykona się na nią 5 backupów
a w ciągu tygodnia 20 (25) i ustawić to w Maximum Volume Jobs ?
Ile zapisów wytrzyma taśma w takim cyklu?

Może mi ktoś podpowiedzieć, czy zmierzam w dobrym kierunku, ewentualnie doradzić jak powinienem zbudować plan (nie chodzi o szczegółowy plan - to sobie doczytam,
tylko o kierunek)

Pozdrawiam

TomB Napisał(a):
-------------------------------------------------------
> 1 .
> Do tej pory zainstalowałem serwer w wersji 7.4.7,
> wstępnie skonfigurowałem i wykonałem testowy
> backup.
Mam nadzieję, że był to backup bazy katalogowej.

> Backup zawierał 5Mln plików i 1TB danych.
> Całość trwała ponad 13 godzin, co daje jakieś
> 23MB/s. (sieć 1Gb)
> Pierwsze pytanie - czy to jest dobry wynik - bo
> spodziewałem się lepszego (100MB/s ??) ?
Wszystko zależy od możliwości i konfiguracji (optymalnej) Twojego środowiska. Możliwe, że można lepiej ale równie dobrze to może być skraj możliwości Twojej infrastruktury. Na tak postawione pytanie bardzo trudno jest odpowiedzieć.

> 2.
> Chciałbym upewnić się co do zasady tworzenia
> backup(ów).
>
> Moim celem jest wykonanie na początek backupów z
> pięciu serwerów (klientów).
> Cztery lokalizacje po około 200GB danych i jedna
> około 600GB razem około 1,5TB
>
> Przy takim czasie jak wyliczyłem dla backupu
> testowego, pełny backup zajmie mi jakieś 15-16
> godzin.
To założenie jest w mojej ocenie niepoprawne. Zakładając, że wydajność Twojego środowiska jest większa i nie napotkałeś na utylizacje samego serwera, to dodanie kolejnego serwera nie musi oznaczać, że wydajność backupu będzie na tym samym poziomie.
Proponuję poczytać sobie o pewnym wdrożeniu: http://bacula.com.pl/category/wpisy/scannet-story, gdzie użytkownik tak opisał swoje osiągi: "(...) Uruchamialiśmy po 100 zadań backupowych w jednym czasie dla każdego łańcucha Dyrektor—Demon Składowania—Katalog, pompując w sumie około 2GB/s do naszych demonów składowania. (...)"
Owszem jego środowisko różniło się znacząco od Twojego (backup na dyski, oddzielony Storage Deamon od Director + Catalog, itp.) ale to pokazuje że Bacula skaluje się do bardzo dobrych parametrów.

> (nie próbowałem ustawiać jeszcze Spool
> Attributes)
Błąd!
A dokładniej to spoolowanie jest rekomendowane przy każdym backupie na taśmy, chyba że strumień danych jaki możemy zapewnić jest co najmniej kilkadziesiąt procent większy niż minimalna szybkość zapisu na taśmę.

> Planowałem wykonywać plan backup w oparciu o
> tzw. advanced 5 day GFS (1 roczna retencja, 18
> tasiemek)
Bacula w specyficzny sposób wspiera cykl backupowy oparty o GFS. Nie liczyłem, ale skąd wiesz że będzie tego 18 tasiemek? Tak pytam, z ciekawości.

> Do wyboru mam takie drogi:
> Pierwsza - robić backup z klientów na dysk w
> storage i dopiero później na LTO
To możesz sobie automatycznie zapewnić za pomocą spoolingu. Zresztą zawsze warto wdrożyć D2D2T o ile masz odpowiednio dużo przestrzeni dyskowej.

> Druga - robić backup z klientów bezpośrednio
> na LTO
Bez spoolingu nie polecam, chyba że masz gwarancję osiągnięcia minimalnej szybkości zapisu danych na taśmy.

> trzecia - robić backup dzienny z klientów
> na storage a tygodniowy i miesięczny na LTO
Ale to bardziej plan gdzie chcę/mogę trzymać swoje archiwa niż plan wydajnościowy.

> czwarta - inny??
Po pierwsze weryfikacja gdzie są ograniczenia (bottleneck) wydajności, tuning i poprawna konfiguracja. Dopiero potem optymalizacja miejsca składowania (D2D2T).

> Czy w przypadku gdy będę chciał robić backup z
> klientów bezpośrednio na LTO
> muszę zdefiniować tyle job-ów, ile mam
> klientów
Nie ma innej możliwości. W Bacula nie da się jednym zadaniem zrobić backup z dwóch klientów jednocześnie.

> i uwzględnić w harmonogramie
> uruchamianie job-ów z odpowiednim przesunięciem
> czasowym?
A dlaczego nie chcesz wykonywać backupów równolegle. Można śmiało postawić tezę, że równoległe wykonanie backupów będzie zawsze szybsze (w krótszym czasie) niż kolejne wykonywanie tych samych zadań backupowych po kolei (oczywiście przy pewnych warunkach o których było wcześniej).

> Co jeśli przewidzę zbyt krótki czas na
> wykonanie job-a?
A to już zależy od tego czy dla Twoich klientów to będzie problem czy nie.

> Czy jeśli chcę wykorzystać jedną taśmę na
> backupy dniowe w tygodniu, muszę uwzględnić,
> że w ciągu jednego dnia wykona się na nią 5
> backupów
> a w ciągu tygodnia 20 (25) i ustawić to w
> Maximum Volume Jobs ?
W mojej ocenie dla backupów na taśmy nie powinieneś ustawiać tego ograniczenia, będziesz miał z tym więcej problemów niż ulotnych korzyści.

> Ile zapisów wytrzyma taśma w takim cyklu?
Ale dokładnie w jakim cyklu? Co jaki czas będziesz tą samą taśmę nadpisywał? Ile masz dostępnych taśm?

> Może mi ktoś podpowiedzieć, czy zmierzam w
> dobrym kierunku, ewentualnie doradzić jak
> powinienem zbudować plan (nie chodzi o
> szczegółowy plan - to sobie doczytam,
> tylko o kierunek)
Najpierw wymagania, a potem polityka backupowa. Nigdy odwrotnie. Robienie odwrotnie to jak budowanie domu od dachu. Niby można i technicznie wykonalne ale jakoś przez tysiąclecia utarło się że powinno się najpierw postawić fundamenty.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

Dziękuję za odpowiedź.
Trudno mi się tutaj poruszać.

Zdefiniowałem własny, trochę zmodyfikowany GFS z wymianą tasiemki raz w tygodniu, ale nie potrafię wstawić grafiki.
O tym będzie niżej

Nie wiem też jak odpowiedzieć z automatu z cytatem... ale to nie na temat

>Bacula w specyficzny sposób wspiera cykl backupowy oparty o GFS.
Co masz na myśli?

>Nie liczyłem, ale skąd wiesz że będzie tego 18 tasiemek? Tak pytam, z ciekawości.
Zamówiłem e-booka na amazonie (Heitor Faria 'The OpenSource Backup Software'), gdzie znalazłem kilka grafik z modelami GFS.

>Proponuję poczytać sobie o pewnym wdrożeniu:
Dziękuję, poczytam

>Nie ma innej możliwości. W Bacula nie da się jednym zadaniem zrobić backup z dwóch klientów jednocześnie
Jasne

>A dlaczego nie chcesz wykonywać backupów równolegle.
Nie rozumiem.
Mogę równolegle wykonywać zadania na taśmę?

Wiem, że na razie mało wiem, ale czytam


>Ale dokładnie w jakim cyklu? Co jaki czas będziesz tą samą taśmę nadpisywał? Ile masz dostępnych taśm?
NO właśnie.
Cykl miał być taki, że dwie taśmy rotacyjnie tydzień pierwsza, tydzień druga.
Później inne tasiemki na zapisy tygodniowe, miesięczne.
Te dwie taśmy miały być w cyklu F, D, D, D
W ciągu dnia zapis na tasiemkę z 5 klientów, w cyklu F ~ 1,5T
Poza tym pozostaje jeszcze kwestia ewentualnej kompresji.

Tasiemek mam 24.

Po przemyśleniach chciałbym zastosować cykl taki:
Wkładam tasiemkę 1 w piątek po południu, w sobotę robi się cykl F.
Od poniedziałku do piątku cykl D i tasiemka 1 wędruje na półkę ("nie ruszać") a do napędu wkładam tasiemkę 2.
W sobotę F. Od poniedziałku do piątku cykl D, wkładam tasiemkę 3
W sobotę F. Od poniedziałku do piątku cykl D, wkładam tasiemkę 4
W sobotę F. Od poniedziałku do piątku cykl D wkładam tasiemkę 2 (pierwsza retencja)
W sobotę F. Od poniedziałku do piątku cykl D i tasiemka 2 wędruje na półkę ("nie ruszać"), a do napędu wkładam tasiemkę 3 (retencja)
itd
Na półce odkładam miesięczne kopie, przy minimum obsługi.

Czy to ma sens?

Pozdrawiam

Mam jeszcze pytanie dt. archiwum
Czy jeśli utworzę na taśmie archiwum tak jak uczyniłem pisząc w poście #1 (Backup zawierał 5Mln plików i 1TB danych)
mogę usunąć z bazy danych te 5mln rekordów czy muszą tam pozostać?
Czy jeśli je usunę stracę możliwość przywrócenia danych z taśmy?
Czy w ogóle coś na tym stracę?

TomB Napisał(a):
-------------------------------------------------------
> Dziękuję za odpowiedź.
> Trudno mi się tutaj poruszać.
Jeśli coś nie działa to zawsze możesz zgłosić się z tym do gani - admin forum.

> Zdefiniowałem własny, trochę zmodyfikowany GFS
> z wymianą tasiemki raz w tygodniu, ale nie
> potrafię wstawić grafiki.
Z tego co widzę, to wstawianie grafiki jest realizowane tylko z zewnętrznego url.

> Nie wiem też jak odpowiedzieć z automatu z
> cytatem... ale to nie na temat
Jest przycisk "Cytuj".

> >Bacula w specyficzny sposób wspiera cykl
> backupowy oparty o GFS.
> Co masz na myśli?
Wymaga np. 3 oddzielnych puli wolumenów i odpowiedniej konfiguracji terminarza czy samego zadania.

> >Nie liczyłem, ale skąd wiesz że będzie tego
> 18 tasiemek? Tak pytam, z ciekawości.
> Zamówiłem e-booka na amazonie (Heitor Faria 'The
> OpenSource Backup Software'), gdzie znalazłem
> kilka grafik z modelami GFS.
OK, muszę zapytać o to Heitora.

> >A dlaczego nie chcesz wykonywać backupów
> równolegle.
> Nie rozumiem.
> Mogę równolegle wykonywać zadania na taśmę?
Oczywiście że można nawet na kilka sposobów. Rekomendowanym jest wykorzystanie spoolingu, ale o tym już pisałem wcześniej.

> Wiem, że na razie mało wiem, ale czytam
To proponuję szkolenie Bacula Administracja I. Można się dowiedzieć wszystkiego od podstaw i przetrenować zdobytą wiedzę.

> >Ale dokładnie w jakim cyklu? Co jaki czas
> będziesz tą samą taśmę nadpisywał? Ile masz
> dostępnych taśm?
> NO właśnie.
> Cykl miał być taki, że dwie taśmy rotacyjnie
> tydzień pierwsza, tydzień druga.
Da się to zrobić.

> Później inne tasiemki na zapisy tygodniowe,
> miesięczne.
Czyli trzy oddzielne pule wolumenów.

> Te dwie taśmy miały być w cyklu F, D, D, D
Ale wiesz co to jest poziom Differential w Bacula? Moim osobistym zdaniem używanie takiego cyklu jest bez sensu. Ma same wady (zabiera dużo czasu i miejsca) i tylko jedną zazwyczaj nieistotną zaletę (złożenie restoru to zawsze tylko dwa zadania zamiast np. 3 ).

> W ciągu dnia zapis na tasiemkę z 5 klientów, w
> cyklu F ~ 1,5T
Tego nie rozumiem.

> Poza tym pozostaje jeszcze kwestia ewentualnej
> kompresji.
Jeśli chodzi o kompresję to dla backupów na taśmę zalecane jest korzystanie z kompresji sprzętowej napędu.

> Po przemyśleniach chciałbym zastosować cykl
> taki:
> Wkładam tasiemkę 1 w piątek po południu, w
> sobotę robi się cykl F.
> Od poniedziałku do piątku cykl D i tasiemka 1
> wędruje na półkę ("nie ruszać") a do
> napędu wkładam tasiemkę 2.
To takim cyklem nie osiągniesz schematu GFS.

> W sobotę F. Od poniedziałku do piątku cykl D,
> wkładam tasiemkę 3
> W sobotę F. Od poniedziałku do piątku cykl D,
> wkładam tasiemkę 4
> W sobotę F. Od poniedziałku do piątku cykl D
> wkładam tasiemkę 2 (pierwsza retencja)
To oznacza, że tasiemka nr 1 musi być w innej puli z inną retencją.

> W sobotę F. Od poniedziałku do piątku cykl D i
> tasiemka 2 wędruje na półkę ("nie
> ruszać"), a do napędu wkładam tasiemkę 3
> (retencja)
> itd
To bardzo ekwilibrystyczny cykl backupowy. Nie za bardzo przypomina GFS o którym pisałeś. Takie ręczne zmienianie tasiemek co tydzień wymaga odpowiedniej konfiguracji MaximumUseDuration.

> Na półce odkładam miesięczne kopie, przy
> minimum obsługi.
>
> Czy to ma sens?
Osobiście nie rozumiem po co robisz backupy F + D w pierwszym tygodniu na tasiemkę odkładaną offline. Jak byś robił sam F i odkładał offline to jeszcze miało by to sens. Druga sprawa, to wspomniane przeze mnie codzienne backupy D. Zamiast tego poziomu sensowniej jest korzystać z backupu Incremental.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

>Jest przycisk "Cytuj". smiling smiley
Gdzie? Albo ja jestem ślepy... nie widzę.. albo moja przeglądarka nie widzi..

>Oczywiście że można nawet na kilka sposobów. Rekomendowanym jest wykorzystanie spoolingu, ale o tym już pisałem wcześniej.
To mnie najbardziej interesuje, i na tym się skupię

>OK, muszę zapytać o to Heitora.
o co? o ilość tych tasiemek?
To akurat łatwo policzyć.
W tym 18 tasiemkowym planie dwie tasiemki robią cykliczny backup tygodniowy (tydzień 1, tydzień 2) i w piątki lecą tygodniowe/miesięczne
Gdyby dało się wkleić grafikę...

>To proponuję szkolenie Bacula Administracja I. Można się dowiedzieć wszystkiego od podstaw i przetrenować zdobytą wiedzę.
A jak to wygląda i jaka jest cena?

>Czyli trzy oddzielne pule wolumenów.
Tak

>> W ciągu dnia zapis na tasiemkę z 5 klientów, w
>> cyklu F ~ 1,5T
>Tego nie rozumiem.
miałem na myśli to, że pełny backup zajmie 1,5 TB i skłdał się będzie z 5 job-ów z 5 klientów

>Jeśli chodzi o kompresję to dla backupów na taśmę zalecane jest korzystanie z kompresji sprzętowej napędu.
ok

>To bardzo ekwilibrystyczny cykl backupowy.
>Nie za bardzo przypomina GFS o którym pisałeś. Takie ręczne zmienianie tasiemek co tydzień wymaga odpowiedniej konfiguracji MaximumUseDuration.

Ponieważ nie mam autoloadera, staram się wymyślić najmniej obsługowy plan.
Może niepotrzebnie.

>Osobiście nie rozumiem po co robisz backupy F + D w pierwszym tygodniu na tasiemkę odkładaną offline.
>Jak byś robił sam F i odkładał offline to jeszcze miało by to sens.
>Druga sprawa, to wspomniane przeze mnie codzienne backupy D. Zamiast tego poziomu sensowniej jest korzystać z backupu Incremental.
Ale aby odtworzyć incremental, muszę wkładać wszystkie tasiemki
Ale pewnie masz rację.

Dziękuję.

TomB Napisał(a):
-------------------------------------------------------
> >Jest przycisk "Cytuj". smiling smiley
> Gdzie? Albo ja jestem ślepy... nie widzę.. albo
> moja przeglądarka nie widzi..
Nie pomogę, to pytanie do gani.

> >To proponuję szkolenie Bacula Administracja I.
> Można się dowiedzieć wszystkiego od podstaw i
> przetrenować zdobytą wiedzę.
> A jak to wygląda i jaka jest cena?
[bacula.com.pl] cena obowiązuje tylko jeśli zgłoszenie jest przez firmę Inteos.

> >To bardzo ekwilibrystyczny cykl backupowy.
> >Nie za bardzo przypomina GFS o którym pisałeś.
> Takie ręczne zmienianie tasiemek co tydzień
> wymaga odpowiedniej konfiguracji
> MaximumUseDuration.
>
> Ponieważ nie mam autoloadera, staram się
> wymyślić najmniej obsługowy plan.
> Może niepotrzebnie.
Nie o to chodzi. Klasyczne polityki backupowe jak FIFO, GFS, Hanoi mają swoje zalety ale mają także swoje wymagania. Można sobie wymyślić coś całkowicie swojego dostosowanego do specyficznych potrzeb, ale to już nie będą klasyczne polityki backupowe.

> >Osobiście nie rozumiem po co robisz backupy F +
> D w pierwszym tygodniu na tasiemkę odkładaną
> offline.
> >Jak byś robił sam F i odkładał offline to
> jeszcze miało by to sens.
> >Druga sprawa, to wspomniane przeze mnie codzienne
> backupy D. Zamiast tego poziomu sensowniej jest
> korzystać z backupu Incremental.
> Ale aby odtworzyć incremental, muszę wkładać
> wszystkie tasiemki
Dlaczego twierdzisz że musisz? Bacula nie działa w ten sposób. Które tasiemki trzeba będzie użyć do odtworzenia wynika z tego co chcesz odtworzyć, a decyzja podejmowana jest na podstawie bazy katalogowej, i na której tasiemce faktycznie się znajduje. To może oznaczać użycie większej ilości tasiemek ale nie musi.
Biorąc pod uwagę, że dla przedstawionego przez Ciebie cyklu na jednej i tej samej tasiemce masz zarówno backup F jak i pozostałe (D czy rekomendowany I) to nigdy nie będziesz potrzebował innej tasiemki niż ta z danego tygodnia. Ja tu nie widzę problemu.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

>Biorąc pod uwagę, że dla przedstawionego przez Ciebie cyklu na jednej i tej samej tasiemce masz zarówno backup F jak i pozostałe (D czy rekomendowany I) to nigdy nie będziesz potrzebował innej >tasiemki niż ta z danego tygodnia. Ja tu nie widzę problemu.
Masz rację!

uwaga do gani:
Brakuje mi też (nie widzę?) możliwości edycji wysłanego postu.
Czasem zauważy się jakąś literówkę lub chce się coś dopisać

Mam pytanie
Do spoolingu w device deklaruję Spool Directory.
Czy ta przestrzeń musi mieć wielkość odpowiadającą (a nawet większą) od wielkości danych, którą chcę zapisać na taśmę?
Mam nadzieję, że nie, bo to trochę przerażające...

TomB Napisał(a):
-------------------------------------------------------
> Mam pytanie
> Do spoolingu w device deklaruję Spool Directory.
> Czy ta przestrzeń musi mieć wielkość
> odpowiadającą (a nawet większą) od wielkości
> danych, którą chcę zapisać na taśmę?
Nie, ale sensowne aby dla pojedynczego zadania "zagwarantowane" było co najmniej kilka a najlepiej kilkanaście/kilkadziesiąt GB. Jak zadań jednocześnie masz 5 i dostępna przestrzeń na spool to 100GB, to należy ustawić ograniczenie dla pojedynczego zadania na co najmniej 25GB.

> Mam nadzieję, że nie, bo to trochę
> przerażające...
Takie wymaganie jest (z wieloma innymi zmiennymi i ograniczeniami/wymaganiami, itp. czyli sporo gwiazdek) w przypadku D2D2T z backupem najpierw na dyski i migracją backupów na taśmy.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

Spool Directory - to folder na plik tymczasowy generowany do nagrania na tasiemkę. A sam plik możemy ograniczyć podając jego maksymalna wielkość np 200GB.

[www.bacula.org]

Witam

Zadania wykonują się równolegle, ale wydaje mi się, że spoolnig nie działa.
Czy coś źle ustawiłem?
Włożyłem dysk do serwera, podmontowałem i ustawiłem w Spool Directory = /mnt/buffer

Wkleję kawałek obecnej konfiguracji, w której równolegle uruchamiam dwa zadania

Device {
Name = LTO6-D
Media Type = LTO-6
Archive Device = /dev/nst0
AutomaticMount = yes;
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
Maximum Spool Size = 255gb
Maximum Job Spool Size = 50gb
Spool Directory = /mnt/buffer
Label media = Yes;
Maximum Changer Wait = 3d

#Tego jeszcze nie rozumiem
#Changer Command = "/etc/bacula/scripts/mtx-changer %o %a %S"
#Changer Device = /dev/null
}

Schedule {
Name = "tape_gfs-schedule"
Run=Incremental Pool=Daily-Tape mon-thu at 09:45
Run=Differential Pool=Weekly-Tape 2nd-5th fri at 21:00
Run=Full Pool=Monthly-Tape 1st fri at 21:00
}

#DIR-POOLS#

Pool {
Name = Daily-Tape
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Use Duration = 20 hours
Volume Retention = 6 days
Cleaning Prefix = "CLN"
Storage = LTO6-S
Maximum Volumes = 100 # Limit number of Volumes in Pool
Label Format = "day-${NumVols}"
}

Pool {
Name = Weekly-Tape
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Use Duration = 3 days
Volume Retention = 27 days
Cleaning Prefix = "CLN"
Storage = LTO6-S
Maximum Volumes = 100 # Limit number of Volumes in Pool
Label Format = "week-${NumVols}"
}

Pool {
Name = Monthly-Tape
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Use Duration = 3 days
Volume Retention = 362 days
Cleaning Prefix = "CLN"
Storage = LTO6-S
Maximum Volumes = 100 # Limit number of Volumes in Pool
Label Format = "month-${NumVols}"
}

#DIR-CLI#

Client {
Name = ts-rnd-fd
Address = 10.0.0.214
FDPort = 9102
Catalog = MyCatalog
Password = "..."
File Retention = 1 year
Job Retention = 1 year
AutoPrune = yes
}

Client {
Name = ts-it-fd
Address = 10.0.0.106
FDPort = 9102
Catalog = MyCatalog
Password = "..."
File Retention = 1 year
Job Retention = 1 year
AutoPrune = yes
}

#DIR-FS#

FileSet {
Name = "ts-it-fs"
Include {
Options { Signature = MD5 }
File = "e:/"
}
}

FileSet {
Name = "ts-rnd-fs"
include {
Options { Signature = MD5 }
File = "p:/"
File = "u:/"
File = "w:/"
}
}

#DIR-JOB#

Job {
Name = "ts-rnd-job"
Client = ts-rnd-fd
Type = Backup
FileSet="ts-rnd-fs"
Pool = Daily-Tape
Schedule = "tape_gfs-schedule"
SpoolAttributes = yes
SpoolData = yes
Write Bootstrap = "/var/lib/bacula/%n.bsr"
Priority = 5
Messages = Standard
}

Job {
Name = "ts-it-job"
Client = ts-it-fd
Type = Backup
FileSet="ts-it-fs"
Pool = Daily-Tape
Schedule = "tape_gfs-schedule"
SpoolAttributes = yes
SpoolData = yes
Write Bootstrap = "/var/lib/bacula/%n.bsr"
Priority = 5
Messages = Standard
}

Podglądam mój folder /mnt/buffer jest w nim tylko pusty podfolder lost+found
Z kolei wieczorny backup o pojemności 90GB zapisywał się z prędkością 17MB/s czyli około 1GB/min.
Storage: "LTO6-S" (From Pool resource)
Scheduled time: 19-kwi-2017 21:20:00
Start time: 19-kwi-2017 21:20:04
End time: 19-kwi-2017 22:49:00
Elapsed time: 1 hour 28 mins 56 secs
Priority: 5
FD Files Written: 160,403
SD Files Written: 160,403
FD Bytes Written: 91,535,689,342 (91.53 G
SD Bytes Written: 91,571,884,479 (91.57 G
Rate: 17154.4 KB/s

serwer z kontrolerem podłączonym do LTO6 jak i serwery z których zapisuję dane na taśmy są wpięte w switch cisco 48/1000
Nie sądzę, by był to problem sieci, obciążonej w ułamku.

Hm, jednak spooling ruszył...
Ale mam problem z auto labelem.
O ile wczoraj automatycznie nadał mi się label day-0, dzisiaj odmontowałem tasiemkę i włożyłem nową.
Job-y uruchomiły się i "mieliły" cały czas status running, choć widziałem, że nic się nie dzieje.
Doszedłem po logach, że oczekuje tasiemki day-0 a nie nadał automatycznie kolejnego.
Po ręcznym nadaniu label day-1 i zamontowaniu taśmy backup ruszył z miejsca.

Co jest nie tak w konfiguracji?

TomB Napisał(a):
-------------------------------------------------------
> Hm, jednak spooling ruszył...
> Ale mam problem z auto labelem.
> O ile wczoraj automatycznie nadał mi się label
> day-0, dzisiaj odmontowałem tasiemkę i
> włożyłem nową.
> Job-y uruchomiły się i "mieliły" cały czas
> status running, choć widziałem, że nic się nie
> dzieje.
> Doszedłem po logach, że oczekuje tasiemki day-0
> a nie nadał automatycznie kolejnego.
Jaki jest status tasiemki day-0? Jeśli Append to dla Bacula ta tasiemka jest gotowa do wykonania backupu i dlatego chciała jej użyć. Nie było sensu etykietować nowej tasiemki.

> Po ręcznym nadaniu label day-1 i zamontowaniu
> taśmy backup ruszył z miejsca.
Bo Bacula zawsze prosi o zamontowanie wskazanej tasiemki (w tym przypadku day-0) lub zaetykietowanie nowej we wskazanej puli. Nie zamontowałeś poprzedniej tasiemki, tylko zaetykietowałeś nową to backupy ruszyły. Jeśli obie tasiemki mają aktualnie status Append to teraz będziesz miał coraz ciekawiej z każdym kolejnym backupem.

> Co jest nie tak w konfiguracji?
Nie masz ustawionego automatycznego "zamykania" wolumenów (np. poprzez volumeuseduration).

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

Mam nadzieję, że nie zaśmiecam wątku, ale wkleję dwa logi:

1. Test napędu narzędziem btape

*speed file_size=3 skip-raw
btape: btape.c:1081-0 Test with zero data and bacula block structure.
btape: btape.c:959-0 Begin writing 3 files of 3.221 GB with blocks of 64512 bytes.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
btape: btape.c:606-0 Wrote 1 EOF to "LTO6-D" (/dev/nst0)
btape: btape.c:405-0 Volume bytes=3.221 GB. Write rate = 140.0 MB/s
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
btape: btape.c:606-0 Wrote 1 EOF to "LTO6-D" (/dev/nst0)
btape: btape.c:405-0 Volume bytes=3.221 GB. Write rate = 134.2 MB/s
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
btape: btape.c:606-0 Wrote 1 EOF to "LTO6-D" (/dev/nst0)
btape: btape.c:405-0 Volume bytes=3.221 GB. Write rate = 140.0 MB/s
btape: btape.c:379-0 Total Volume bytes=9.663 GB. Total Write rate = 138.0 MB/s

btape: btape.c:1093-0 Test with random data, should give the minimum throughput.
btape: btape.c:959-0 Begin writing 3 files of 3.221 GB with blocks of 64512 bytes.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
btape: btape.c:606-0 Wrote 1 EOF to "LTO6-D" (/dev/nst0)
btape: btape.c:405-0 Volume bytes=3.221 GB. Write rate = 119.3 MB/s
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
btape: btape.c:606-0 Wrote 1 EOF to "LTO6-D" (/dev/nst0)
btape: btape.c:405-0 Volume bytes=3.221 GB. Write rate = 115.0 MB/s
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
btape: btape.c:606-0 Wrote 1 EOF to "LTO6-D" (/dev/nst0)
btape: btape.c:405-0 Volume bytes=3.221 GB. Write rate = 115.0 MB/s
btape: btape.c:379-0 Total Volume bytes=9.663 GB. Total Write rate = 116.4 MB/s


2. Log po wykonaniu zadania

Backup Level: Full (upgraded from Incremental)
Client: "ts-rnd-fd" 5.2.10 (28Jun12) Microsoft Windows Server 2008 R2 Enterprise Edition Service Pack 1 (build 7601), 64-bit,Cross-compile,Win64
FileSet: "ts-rnd-fs" 2017-04-19 21:00:00
Pool: "Daily-Tape" (From Run Pool override)
Catalog: "MyCatalog" (From Client resource)
Storage: "LTO6-S" (From Pool resource)
Scheduled time: 20-kwi-2017 09:45:00
Start time: 20-kwi-2017 15:35:00
End time: 20-kwi-2017 19:21:19
Elapsed time: 3 hours 46 mins 19 secs
Priority: 5
FD Files Written: 2,167,968
SD Files Written: 2,167,968
FD Bytes Written: 549,529,951,726 (549.5 G
SD Bytes Written: 550,042,967,581 (550.0 G
Rate: 40469.1 KB/s
Software Compression: None
Snapshot/VSS: yes
Encryption: no
Accurate: no
Volume name(s): day-1
Volume Session Id: 5
Volume Session Time: 1492629492
Last Volume Bytes: 551,030,538,240 (551.0 G
Non-fatal FD errors: 0
SD Errors: 6
FD termination status: OK
SD termination status: OK
Termination: Backup OK -- with warnings
deb-lto-sd JobId 69: Sending spooled attrs to the Director. Despooling 854,279,379 bytes ...
deb-lto-sd JobId 69: Elapsed time=03:38:44, Transfer rate=41.91 M Bytes/second
deb-lto-sd JobId 69: Despooling elapsed time = 00:00:06, Transfer rate = 103.9 M Bytes/second
deb-lto-sd JobId 69: Committing spooled data to Volume "day-1". Despooling 623,542,886 bytes ...
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "COM+ REGDB Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "SqlServerWriter", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "TermServLicensing", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "Shadow Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "Registry Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "ASR Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "IIS Config Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "WMI Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "System Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "VSS Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
ts-rnd-fd JobId 69: VSS Writer (BackupComplete): "Task Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:09:49, Transfer rate = 84.88 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,498 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,498 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:11:04, Transfer rate = 75.30 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,032,989 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,032,989 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:10:37, Transfer rate = 78.49 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,779 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,779 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:10:51, Transfer rate = 76.80 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,034,014 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,034,014 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:10:27, Transfer rate = 79.74 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,249 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,249 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:10:19, Transfer rate = 80.77 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,032,722 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,032,722 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:10:27, Transfer rate = 79.74 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,262 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,262 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:09:53, Transfer rate = 84.31 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,806 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,806 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:09:41, Transfer rate = 86.05 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,775 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,775 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:10:02, Transfer rate = 83.05 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,417 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,417 MaxJobSpoolSize=50,000,000,000
deb-lto-sd JobId 69: Spooling data again ...
deb-lto-sd JobId 69: Despooling elapsed time = 00:10:36, Transfer rate = 78.61 M Bytes/second
deb-lto-sd JobId 69: Writing spooled data to Volume. Despooling 50,000,033,914 bytes ...
deb-lto-sd JobId 69: User specified Job spool size reached: JobSpoolSize=50,000,033,914 MaxJobSpoolSize=50,000,000,000
ts-rnd-fd JobId 69: Generate VSS snapshots. Driver="Win64 VSS", Drive(s)="PUW"
deb-lto-sd JobId 69: Spooling data ...
deb-lto-sd JobId 69: Wrote label to prelabeled Volume "day-1" on tape device "LTO6-D" (/dev/nst0)



Czy ktoś może mi wytłumaczyć, dlaczego prędkość zapisu wynosi tylko 40MB/s ?? Rate: 40469.1 KB/s

Z testu wyszło, że Write rate jest na poziomie 115.0 MB/s
Z testu iperf wyszło mi, że przez sieć przepuszcza ponad 900Mb/s

Spooling przyspieszył czas zapisu dwukrotnie, z około 20MB/s do 40MB/s, ale co to jest za prędkość?

>Jaki jest status tasiemki day-0?
Append
A - czyli co , nie może zostać status append?
Po 6 dniach i tak wejdzie retencja (Volume Retention = 6 days)

>Bo Bacula zawsze prosi o zamontowanie wskazanej tasiemki (w tym przypadku day-0) lub zaetykietowanie nowej we wskazanej puli. Nie zamontowałeś poprzedniej tasiemki, tylko zaetykietowałeś nową >to backupy ruszyły. Jeśli obie tasiemki mają aktualnie status Append to teraz będziesz miał coraz ciekawiej z każdym kolejnym backupem

Czy przyczyną jest to, że "volume use duration" mam ustawione na 20 godz. a zmieniłem (jak to przy testach) rano harmonogram z godz. 21:00 na 9:45, żeby uruchomić wcześniej zadanie?
Czy w przypadku tasiemek jest sens "labelować" automatycznie, czy lepiej zestaw tasiemek nadawać label ręcznie?

Jeszcze odnoście prędkości zapisu.

Czy jest sens zmieniać ustawienia Maximum Block Size w bacula-sd.conf?
Szczerze mówiąc nie wiem jaki jest domyślny parametr, bo w pliku nie mam jawnie tego ustawienia.

Czy pomoże tuning bazy danych?
Heitor podaje kilka ustawień, które można zmienić/poprawić

bacula ma rozmiar bloku 64512 ... niestety o tuningu tego parametru nie słyszałem ...

Ja na razie ustawiłem:
MaximumBlockSize = 524288 #512k
Maximum File Size = 10000000000 #10GB

możesz też poczytać tutaj:
optimizing_tape_speed
i tutaj
actions-to-avoid

TomB Napisał(a):
-------------------------------------------------------
> >Jaki jest status tasiemki day-0?
> Append
> A - czyli co , nie może zostać status append?
Nie.
> Po 6 dniach i tak wejdzie retencja (Volume
> Retention = 6 days)
Retencja liczona jest od wartości LastWritten danego wolumenu ale tylko w przypadku kiedy jest status jest Full lub Used.

> Czy przyczyną jest to, że "volume use duration"
> mam ustawione na 20 godz. a zmieniłem (jak to
> przy testach) rano harmonogram z godz. 21:00 na
> 9:45, żeby uruchomić wcześniej zadanie?
VUD będzie aktywne dopiero podczas uruchomienia zadania korzystającego z danej puli, jeśli LastWritten + VUD już upłynął.

> Czy w przypadku tasiemek jest sens "labelować"
> automatycznie, czy lepiej zestaw tasiemek nadawać
> label ręcznie?
Jeśli korzystałbyś z biblioteki taśmowej, to labelowanie powinno odbyć się ręcznie na podstawie barkodów. A ręcznie to jak stryjenka uważa - ja nigdy nie labeluję automatycznie tasiemek.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

Czy da się estymować zadanie, zdefiniowane w schedulerze?
np. u mnie
Schedule {
...
Run=Differential Pool=Weekly-Tape 2nd-5th fri at 21:00
}

W kilku job-ach mam wskazanie do puli i schedulera.

Wiem jak estymować pojedyncze zadania, a jak estymować wszystkie zadania z puli?
Muszę estymować je pojedynczo?

Nie rozumiem też jak działa ten volume use duration
Wydawało mi się, że skoro ustawiłem vud na 20h, to po 20h wolumen powinien zmienić status na used.
Tymczasem wolumen zapisany 48h temu, nadal ma status append
co to znaczy
"będzie aktywne dopiero podczas uruchomienia zadania korzystającego z danej puli, jeśli LastWritten + VUD już upłynął"


Czy powinienem użyć "use Volume Once"?

możesz użyć bash-a jakiś skrypcik

echo "estimate job=nazwa-job-a" | bconsole

Po ustawieniu

MaximumBlockSize = 524288 #512k
Maximum File Size = 10gb

nie zauważyłem różnicy w prędkości zapisu.

Mam jeszcze takie pytanie:
Jak Bacula radzi sobie z plikami o dużych rozmiarach (kilkadziesiąt G, np. backup bazy danych, obraz maszyny wirtualnej itp. ?
Czy ustawienia
Maximum Spool Size
Maximum Job Spool Size
mają znaczenie (zwłaszcza, gdy wielkość pliku przekracza MSS lub MJS)?

Pozdrawiam

TomB Napisał(a):
-------------------------------------------------------
> Mam jeszcze takie pytanie:
> Jak Bacula radzi sobie z plikami o dużych
> rozmiarach (kilkadziesiąt G, np. backup bazy
> danych, obraz maszyny wirtualnej itp. ?
Nie ma różnicy, i to plik i to plik.

> Czy ustawienia
> Maximum Spool Size
> Maximum Job Spool Size
> mają znaczenie (zwłaszcza, gdy wielkość pliku
> przekracza MSS lub MJS)?

MSS/MJS to tylko bufor. Jak się skończy to Bacula zapisuje jego zawartość na taśmę i kontynuuje dalej backup. Nie ma znaczenia czy w buforze było miliard małych plików czy fragment jednego dużego.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

Próbuję zrobić backup maszyny wirtualnej za pomocą bpipe

Środowsko Xen Server 7.0
Klient skompilowany, włączony plugin.


ustawienia:
#
FileSet {
Name = "xen7test-odoo8-fs"
Include {
Options { Signature = MD5 }
Plugin = "bpipe:/var/Odoo_8.xva:snapshot=`xe vm-snapshot uuid=1f3cfdde-e0fd-65e5-bea2-2a4a8e0abd0f new-name-label=Odoo_8_snps` &&
xe template-param-set is-a-template=false uuid=$snapshot && xe vm-export vm=$snapshot filename=:dd of=/mnt/Odoo_8.xva"
}
}
Snapshoot się tworzy i to tyle.
Job terminated z błędem.

Czym może być spowodowany taki błąd, bo już nie mam pomysłu.

...
Non-fatal FD errors: 1
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK -- with warnings
deb-lto-sd JobId 117: Sending spooled attrs to the Director. Despooling 270 bytes ...
deb-lto-sd JobId 117: Elapsed time=00:00:04, Transfer rate=134 Bytes/second
deb-lto-sd JobId 117: Despooling elapsed time = 00:00:01, Transfer rate = 1.043 K Bytes/second
deb-lto-sd JobId 117: Committing spooled data to Volume "days-1". Despooling 1,043 bytes ...
xen7test-fd JobId 117: Error: bpipe-fd: Error closing for file /var/tmp/Odoo_8.xva: 268435457
deb-lto-sd JobId 117: Spooling data ...
deb-lto-dir JobId 117: Using Device "LTO6-D" to write.
deb-lto-dir JobId 117: Start Backup JobId 117, Job=XS7-job-odoo8.2017-04-27_14.10.00_09

Przepraszam, w poście wyżej wkleiłem stary fileset
powinno być:
Plugin = "bpipe:/var/tmp/Odoo_8.xva:snapshot=`xe vm-snapshot uuid=1f3cfdde-e0fd-65e5-bea2-2a4a8e0abd0f new-name-label=Odoo_8_snps` &&
xe template-param-set is-a-template=false uuid=$snapshot && xe vm-export vm=$snapshot filename=:dd of=/mnt/Odoo_8.xva"

Zawsze jak masz problem to powinieneś podesłać całość logu zadania, a nie tylko fragment.
Inna sprawa to to, że komenda do wykonania w bpipe to nie jest shell tylko standardowy exec(3), więc nie będzie to tak działać jak zrobiłeś.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]

>Inna sprawa to to, że komenda do wykonania w bpipe to nie jest shell tylko standardowy exec(3), więc nie będzie to tak działać jak zrobiłeś.

Dlaczego?
Skorzystałem z przykładu Heitora, który był testowany i używany również przez innych użytkowników baculi.

Oto cały log

deb-lto-dir JobId 117: End auto prune.
deb-lto-dir JobId 117: No Files found to prune.
deb-lto-dir JobId 117: Begin pruning Files.
deb-lto-dir JobId 117: No Jobs found to prune.
deb-lto-dir JobId 117: Begin pruning Jobs older than 1 year .
deb-lto-dir JobId 117: Bacula deb-lto-dir 7.4.7 (16Mar17):
Build OS: x86_64-unknown-linux-gnu debian 8.7
JobId: 117
Job: XS7-job-odoo8.2017-04-27_14.10.00_09
Backup Level: Full
Client: "xen7test-fd" 7.4.6 (10Mar17) x86_64-unknown-linux-gnu,redhat,
FileSet: "xen7test-odoo8-fs" 2017-04-27 14:10:00
Pool: "Daily-Tape" (From Run Pool override)
Catalog: "MyCatalog" (From Client resource)
Storage: "LTO6-S" (From Pool resource)
Scheduled time: 27-kwi-2017 14:10:00
Start time: 27-kwi-2017 14:10:02
End time: 27-kwi-2017 14:10:08
Elapsed time: 6 secs
Priority: 11
FD Files Written: 1
SD Files Written: 1
FD Bytes Written: 186 (186
SD Bytes Written: 537 (537
Rate: 0.0 KB/s
Software Compression: None
Snapshot/VSS: no
Encryption: no
Accurate: no
Volume name(s): days-1
Volume Session Id: 33
Volume Session Time: 1493038048
Last Volume Bytes: 402,760,147,968 (402.7 G
Non-fatal FD errors: 1
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK -- with warnings
deb-lto-sd JobId 117: Sending spooled attrs to the Director. Despooling 270 bytes ...
deb-lto-sd JobId 117: Elapsed time=00:00:04, Transfer rate=134 Bytes/second
deb-lto-sd JobId 117: Despooling elapsed time = 00:00:01, Transfer rate = 1.043 K Bytes/second
deb-lto-sd JobId 117: Committing spooled data to Volume "days-1". Despooling 1,043 bytes ...
xen7test-fd JobId 117: Error: bpipe-fd: Error closing for file /var/tmp/Odoo_8.xva: 268435457
deb-lto-sd JobId 117: Spooling data ...
deb-lto-dir JobId 117: Using Device "LTO6-D" to write.
deb-lto-dir JobId 117: Start Backup JobId 117, Job=XS7-job-odoo8.2017-04-27_14.10.00_09