Newsgroup: it.comp.os.linux.sys
Titolo: Bacula e backup incrementali

Ho notato che bacula, giustamente, per poter ripristinare file da un
incrementale, ha bisogno di tutti gli incrementali precedenti fino ad
arrivare ad un full.
Questo significa che, ad esempio, se facessi un full il 1° Giugno più
1 incrementale tutti i giorni seguenti, se il 1° Luglio volessi
ripristinare un file dal backup del 20, dovrei avere il full del 1°,
ed i 19 incrementali fino ad arrivare al 20.
Peccato che non li ho, perchè a quanto pare ho impostato male la
retention.
Non mi importa, ora sistemo, ma quel zuccone di Bacula a quanto pare
fa il purge del full senza portarsi dietro anche tutti i suoi
incrementali, rendendoli, di fatto, inutilizzabili.
Voi cosa avete impostato come retention? Mi piacerebbe avere 2 mesi di
backup per ciascun client, così composti:
1 full il 1° del mese,
1 differenziale ogni domenica
1 incrementale tutti gli altri giorni.
questo significa che dopo 60 giorni avrò 2 full, 8 differenziali e 46
incrementali (6 giorni a settimana, meno i 2 del full)
dico bene? Non vorrei avere brutte sorprese.
Attualmente ho 35 giorni di retention per ciascuna tipologia di
backup, ma pensandoci bene, non può avere senso. L'ultimo
incrementale, quello del 29 del mese, prenderà una retention di 35
giorni, ma il giorno seguente sarà cancellato il purge, rendendolo, di
fatto, inutile.
(per il momento tampono disattivando la retention, li tengo
all'infinito e poi li cancello a mano quando mi serve spazio, almeno
non mi ritrovo con il culo fuori dalla finestra)

 1 incrementale tutti gli altri giorni.
Una politica quasi GFS, ma IMHO non è un approccio orientato al dato
come invece dovrebbe essere con bacula.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 sempre solo due nastri).
Ok, il problema è che non ho capito come calcolare la corretta retention.
Se, ad esempio, facessi un full il 1° del mese con retention 30 giorni,
il trentesimo giorno il full mi viene eliminato.
Considerato che gli incrementali seguenti han bisogno di un full per
poter essere 'validi', non posso impostare 30 giorni di retention anche
a loro, altrimenti l'incrementale del trentesimo giorno avrebbe 24 ore
di validità (visto che il full scade quel giorno li) ma mi restano 
comunque in archivio per 30 giorni di retention.
Capisci che intendo?
Forse devo calcolare la retention del full in modo tale che mi vada a
coprire anche tutte le retention degli incrementali e differenziali:
Full: 30 giorni
Diff: 14 giorni
Incr: 7 giorni
Il settimo giorno gli incrementali scadono, perchè tanto vien fatto un
differenziale al loro posto.
Dopo 14 giorni scade il differenziale, perchè ne viene
fatto uno nuovo il giorno stesso (ovvero 14 giorni dopo il primo) ed
il full scade 30 giorni, coprendo tutti gli altri.
Boh, non ci ho capito una fava, sinceramente. So solo che devo poter 
ripristinare un file fino a 60 giorni prima, se qualcuno mi dicesse come
fare, gli sarei riconoscente per il resto della vita. E devo poter
selezionare da quale backup, ad esempio ripristinare il file "prova"
dal backup di ieri, piuttosto che da quello di 3 giorni fa o di 45 
giorni fa.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 giorni fa.
In questo caso io farei un virtualfull ogni 30 giorni e un differenziale
giornaliero, impostando la retention dei full per 90 giorni e dei
differenziali per 60 giorni.


 differenziali per 60 giorni.
Uhm, vediamo se ci ho capito:
(lasciamo perdere il virtualfull, per ora)
Il full con retention 90 giorni, mi dura 90 giorni.
In questi 90 giorni io posso fare dei 'sottobackup' (diff o incr) purchè
la retention dell'ultimo backup che vado a fare non mi superi i 90
giorni del full (partendo dalla data del full), altrimenti mi resterebbe
orfano.
Facendo un differenziale ogni giorno per 30 giorni ed impostando la
loro retention a 60 giorni, io avrò al massimo 60+30 = 90 giorni di
massima retention, rientrando quindi dentro i 90 giorni di full.
Quando viene segato il full, viene segato anche l'ultimo differenziale.
Quindi così (i trattini sono i giorni):
|FULL -------------------------|
  |diff-------------------|
   |diff-------------------|
    |diff-------------------|
     |diff-------------------|
      |diff-------------------|
       |diff-------------------|
        |diff-------------------|
        ^^^^^^^^^^^^^^^^^^^^^^^^^
          questo, l'ultimo diff, arriva fino
          alla fine della retention del full
Arrivati a sto punto, devo fare in modo che mi venga
generato un nuovo full, ovvero, se l'ultimo backup è
un differenziale del giorno 30, il giorno 30+1 devo
ovviamente generare un nuovo full, altrimenti se facessi
un ulteriore differenziale, avrei la sua retention pari a 31+60 = 91
e mi ritroverei, prima o poi, con il backup orfano.
Sostanzialmente è così ?
(Non mi convince, se ci fai caso, sulla destra, ci sono dei buchi,
questo significa che non posso ripristinare un dato file, per tutta
la durata del full, ovvero 90 giorni, a partire da qualunque diff
come ad esempio il primo.)
Se, invece, stacco completamente la retention e me ne sbatto
allegramente? Non dovrei avere di sti problemi, dico bene?
Così facendo ripristino qualunque file, in qualunque momento,
da qualunque backup, visto che non scadono mai.


          alla fine della retention del full
Boh... non capisco il tuo grafico...
Facciamo così, semplifichiamo dividendo per 10 tutti i numeri coinvolti.
Un full ogni 3 giorni e un differenziale nei rimanenti con retention dei
full per 9 giorni e dei differenziali per 6 giorni.
Chiamiamo Fn l'ennesimo Full mentre chiamiamo DmFn l'emmesimo
differenziale relativo all'ennesimo Full.
Ogni giorno eseguirai un nuovo backup e scadrà un vecchio backup set in
base alla retention, quindi ogni giorno potrai recuperare i dati
relativi ad una diversa data passata.
Giorno	Eseguo	Scade	Giorni restore possibile
1	F1	-	1
2	D1F1	-	1-2
3	D2F1	-	1-3
4	F2	-	1-4
5	D1F2	-	1-5
6	D2F2	-	1-6
7	F3	-	1-7
8	D1F3	-	1-8
9	D2F3	D1F1	1,3-9
10	F4	D2F1	1,4-10
11	D1F4	F1	4-11
12	D2F4	D1F2	4,6-12
13	F5	D2F2	4,7-13
14	D1F5	F2	7-14
15	D2F5	D1F3	7,9-15
Come vedi dalla tabella sopra ogni dato è recuperabile con granularità
di un gionro per 6 giorni, ed è inoltre recuperabile anche il dato
presente nel full precedente.
In sostanza devi sempre avere almeno un full in più per non perdere la
base dei differenziali.


 presente nel full precedente.
Ok.
Quindi tornando ai giorni di cui si parlava in origine, con questo
tuo sistema, togliendo di mezzo gli incrementali, potrei avere
1 full ogni 30 giorni, 1 differenziale ogni giorno, poter recuperare
un dato qualsiasi da un giorno arbitrario fino a 60 giorni fa oppure
un dato qualsiasi di 90 giorni fa.
In sostanza di recuperabile ci sarebbe il giorno 90 più tutti i giorni
da 60 giorni fa ad oggi. Per i giorni tra 61 e 89 non c'è backup, o
ripristino dal
90 (sempre che ci sia) oppure niente.
Se è così, mi può star bene.
Se volessi avere una maggiore copertura, mi basterebbe aumentare la
retention
portando i full a 120 ed i differenziali a 90, dico bene?

 portando i full a 120 ed i differenziali a 90, dico bene?
Sě.


 Sì.
Uhm, ottimo. Per fare ciò mi basta rimuovere il mio attuale
pool incrementale, disattivarlo dallo scheduler e settare
il volume retention dei full a 90gg ed il volume retention
dei differenziali a 60gg ? (considerato che tutto il resto
sta già funzionando, il mio problema è solo inerente la retention)
Mi pare relativamente semplice, domani provo.

 sui log dove non hanno senso).
Vien fuori un problema:
usando i differenziali al posto degli incrementali, più passano i giorni
rispetto alla data del full (quindi fino a 60 giorni, stando sempre alla
tua struttura) più il differenziale diventa mastodontico. (e quindi
richiederà più tempo ad essere portato a termine)
Da quel che leggo, il differenziale è la differenza rispetto al full e
non rispetto al precedente backup, mentre l'incrementale è la differenza
rispetto al precedente backup.
Mi spiego:
supponiamo di fare, il giorno 1, un Full da 100GB
il giorno 2 vengono modificati 10GB di dati
il giorno 3 vengono modificati altri 10GB di dati
il differenziale del giorno 2 sarà 10GB, perchè avrà le sole
differenze riespetto al giorno 1.
il differenziale del giorno 3 sarà 20GB, perchè avrà le differenze
a partire dal full, ovvero avrà tutto il giorno 2 e tutto il giorno 3.
Usando i differenziali, in 3 giorni avrò 100+10+20 = 130GB di backup.
Usando gli incrementali, il giorno 2 avrei 10GB di backup, il giorno 3
avrei sempre 10GB di backup, per un totale di 100+10+10 = 120 GB.
Immagina questo su $molti server con $tanti dati da backuppare ed avrai
una vagonata di spazio buttato via.
Forse il tuo sistema può avere senso usando un VirtualFull ogni
15 giorni, in questo modo il differenziale più grosso sarà quello
del giorno 14, visto che il 15 sarà effettuato un VirtualFull e di
conseguenza il giorno 16 il differenziale partirà da quello.


 per ritrasferire i dati.
Bacula supporta i backup sintetici? Figo, non lo sapevo! ;^)
bye!

 conseguenza il giorno 16 il differenziale partirà da quello.
Per il momento mi son configurato così:
Run = Full on 1 at 22:30
Run = Differential on 2-31 at 22:30
Run = VirtualFull on 15 at 14:00
Il VirtualFull lo faccio a metà giornata, tanto non impatta
sui client e così facendo me lo trovo pronto per il differenziale
della stessa sera (il giorno 15) alle 22:30.
In teoria, i differenziali dal 15 in avanti dovrebbero iniziare
a considerare il VirtualFull anzichè il Full del 1°, quindi avere
a loro volta meno dati da copiare.
Spero di aver capito bene.


 Eh... che programma del beep :-)
E` uno dei motivi per cui ho deciso di scrivermi un sistema di backup per 
fatti miei (ok, non e` vero, ma lo sarebbe stato se avessi saputo che bacula 
faceva una cagata del genere :) )
Enrico

 a loro volta meno dati da copiare.
No, non è vero che lo faccio a metà giornata. Non lo fa proprio.
L'errore è:
07-Jan 12:30 b01-sd JobId 1301: acquire.c:117 Changing read device. Want 
Media Type="mioclient-FileVirtualFull" have="mioclient-File"
   device="mioclient-FileStorage" (/var/bacula/backups/clients/mioclient)
07-Jan 12:30 b01-sd JobId 1301: Fatal error: acquire.c:166 No suitable 
device found to read Volume "20110105_1459-mioclient-virtualfull"
Il Job comprende queste direttive:
    Pool = mioclient-FullPool
    Full Backup Pool = mioclient-FullPool
    Incremental Backup Pool = mioclient-IncrementalPool
    Differential Backup Pool = mioclient-DifferentialPool
Che di default dovrebbero piazzare i backup nel Pool "FullPool"
salvo poi utilizzare un Pool differente se specificato (nel mio
caso, ho un pool per ogni tipologia di backup)
Il Pool di default, ovvero mioclient-FullPool viene letto correttamente,
tant'è che la mail di notifica errore che mi invia bacula, lo rileva e
ne legge il valore di NextPool:
Client:  "mioclient-fd" 2.4.4 (28Dec08) i486-pc-linux-gnu,debian,5.0
FileSet: "Full Set" 2010-11-06 13:12:09
Pool:    "mioclient-VirtualFullPool" (From Job Pool's NextPool resource)
Catalog: "Catalog" (From Client resource)
Storage: "mioclient-StorageVirtualFull" (From Storage from Pool's 
NextPool resource)
Il NextPool specificato nel "mioclient-FullPool" è usato solo per i
backup VirtualFull e contiene questa direttiva:
Storage = "mioclient-StorageVirtualFull"
Lo storage esiste ed è così configurato:
Storage {
    Name = mioclient-StorageVirtualFull
    Address = 172.17.0.1
    SDPort = 9103
    Password = "x"
    Device = "mioclient-FileStorageVirtualFull"
    Media Type = "mioclient-FileVirtualFull"
    Maximum Concurrent Jobs = 5
}
Anche lo Storage Daemon di bacula è configurato correttamente:
Device {
    Name = mioclient-FileStorageVirtualFull
    Device Type = File;
    Media Type = mioclient-FileVirtualFull
    Archive Device = "/var/bacula/backups/clients/mioclient"
    LabelMedia = yes;
    Random Access = yes;
    AutomaticMount = yes;
    Requires Mount=no;
    RemovableMedia = no;
    AlwaysOpen = no;
}
Per quale caspita di motivo sto stronzo maledetto mi dice:
Want Media Type="mioclient-FileVirtualFull" have="mioclient-File"
"mioclient-File" è il Media Type di tutti gli altri Pool, compreso
il Full. Deve leggere dal FullPool e scrivere sul VirtualFullPool
che *NON* ha mioclient-File come MediaType.
La cosa buffa è che sono riuscito a farlo andare 2 giorni fa e la
configurazione era la stessa:
05-Jan 14:59 b01-dir JobId 1023: Using Device 
"mioclient-FileStorageVirtualFull"
Client:  "mioclient-fd" 2.4.4 (28Dec08) i486-pc-linux-gnu,debian,5.0
FileSet: "Full Set" 2010-11-06 13:12:09
Pool:    "mioclient-VirtualFullPool" (From Job Pool's NextPool resource)
Catalog: "Catalog" (From Client resource)
Storage: "mioclient-StorageVirtualFull" (From Storage from Pool's 
NextPool resource)
Stando alla mail di conferma, mi ha letto il FullPool da volume 
corretto, poi è passato a consolidare due Incrementali leggendoli dal 
loro pool scrivendo tutto nel NextPoll indicato.
Bacula è un ottimo software, ma i suoi messaggi di errore sono veramente
una cosa indecente.


 device found to read Volume "20110105_1459-mioclient-virtualfull"
Ho capito la causa.
Il primo VirtualFull lo fa correttamente, il problema, però, si ha
quando deve
generare il secondo. Generando il secondo, cerca di rileggere quello
fatto in
precedenza e non ci riesce e non so per quale motivo.

 quale motivo.
Perché dopo il primo virtualfull il pool di partenza e di destinazione
coincidono. Devi aggiungere un migration job o un copy job dopo il
Virtualfull.
http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/bacula-25/using-the-virtualfull-level-with-disk-backups-100334/


 
http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/bacula-25/using-the-virtualfull-level-with-disk-backups-100334/
Ma che casino.
A 'sto punto, visto che ho capito come funzionano i backup su Bacula,
mi faccio 1 Full al mese, retention 90gg, 1 differenziale a settimana
con retention 60gg e tutti gli altri giorni incrementali sempre con
retention 60gg
Le date dovrebbero corrispondere.
Il primo full è valido dal 1° Gennaio a 31 Marzo (date volutamente non
corrette, mi serve per avere i numeri tutti uguali)
L'ultimo incrementale è valido dal 31 Gennaio al 31 Marzo perchè
ed è coperto dal full del 1° Gennaio.
Il 1° Febbraio ci sarà un nuovo full che va dal 1° febbraio al 31 Aprile
L'incrementale del 2 Febbraio dovrebbe essere fatto a partire dal backup
subito precedente, quindi dal full del 1° Febbraio.
Dico bene? Non vorrei ritrovarmi con una nuova inconsistenza.


 Virtualfull.
No, non coincidono, tant'è che lui si aspetta un certo tipo di media
type
mentre invece ne trova uno differente.
ho anche provato a spostare il volume del virtualfull dentro il pool
dei
full, pensando se lo andasse a ripescare da li, ma se ne sbatte
allegramente
e continua a cercare il mediatype errato.
In pratica, il primo virtualfull lo fa partendo dal FullPool e
scrivendo
la risultante in VirtualFullPool, il secondo (penso anche giustamente)
cerca
di farlo andando prima a leggere il virtualfull da VirtualFullPool ma
usando
lo storage errato, ovvero quello dei Full tradizionali, che ovviamente
non
vanno bene.
Giuro, sto programma mi sta facendo incazzare non poco.
La documentazione dei VirtualFull è 50 righe ed online non si trova
nulla
in merito, sto letteralmente andando 'a caso'.
Ho scritto anche nella loro mailing list, ma sembra che abbiano tutti
praticamente qualche problema con i virtualfull, una delle ultime
risposte
è stata da parte di un utente che pensa che i virtual backup non siano
ancora pronti da usare in produzione.
Non sono il primo ad aver problemi di incongruenze con gli storage
usati.
Bacula usa quello sbagliato.