Newsgroup: it.comp.os.linux.sys
Titolo: rsnapshot

Avete esperienze con rsnapshot?
Ho notato che il cron di default esegue sempre il daily,
indipendentemente dal fatto che lo stesso giorno debba
eseguire un weekly o un monthly.
tant'è che nella documentazione consigliano di eseguire
gli intervalli maggiori dopo quelli inferiori (quindi prima
il daily, poi dopo tot tempo il weekly e così via).
Chiarissimo, serve ad evitare che il weekly parta mentre
il daily è ancora in esecuzione.
Domanda: ma se il mio daily impiega 22 ore a terminare, il
weekly quando lo eseguo?
Siete al corrente di qualche soluzione oppure devo crearmi
io un wrapper che (richiamato ogni giorno dal cron) decide
se eseguire il daily, il weekly e così via in base al giorno
della settimana ?
Non vorrei reinventare la ruota.
-- 
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.


Io lo lancio così dai cron:
# ogni 6 ore per lo snapshot orario
0 */6 * * * /usr/bin/rsnapshot hourly
# ogni giorno alle 2 di notte per lo snapshot giornaliero
30 2 * * * /usr/bin/rsnapshot daily
# uno alla settimana ( la domenica alle 4 del mattino)
0 4 * * 0 /usr/bin/rsnapshot weekly
# eseguiti alle 4:50 nel primo giorno di ogni mese
50 4 1 * * /usr/bin/rsnapshot monthly
----------
rsnapshot.conf
interval        hourly  4
interval        daily   7
interval        weekly  4
interval        monthly 12
24ore/4 = 6 cioè ogni 6 ore
Per la "sovrapposizione", vedo che setta un pid:
lockfile        /var/run/rsnapshot.pid
Quindi suppongo che non partano processi se c'è un pid precedente in 
esecuzione. (ma potrei sbagliarmi)
-- Yena --

 esecuzione. (ma potrei sbagliarmi)
Ok per il pid (la mia configurazione e' parecchio piu' complessa ma il
risultato non cambia) il problema è che in caso di sovrapposizione il
weekly salterebbe.
Ti faccio un esempio:
se mettessi il daily ogni notte alle 00:00 ed il weekly lo stesso
giorno alle 22:00, nel caso il daily durasse più di 22 ore (in alcuni
casi da me e' così) il weekly non partirebbe (per via del lockfile
impostato da daily) e di conseguenza, quella settimana, sarei senza
weekly.
Capisci che intendo?
A logica, non sarebbe più corretto far fare o il daily o il weekly? Ad
esempio, la domenica notte potrebbe aver senso fare il solo weekly
(che si basa sul daily del sabato) piuttosto che un daily più un
weekly, alla fin fine, il contenuto del weekly della domenica
corrisponderebbe anche ad un daily del giorno stesso.
Idem per l'annuale (se si dovesse fare). Che senso avrebbe fare 4
backup quando ne basterebbe uno? L'annuale è per forza di cose anche
un daily, un monthly ed un weekly allo stesso tempo.
così facendo, non ci sarebbero problemi di lock, perchè giornalmente
sarà eseguito sempre e solo un backup, e mai più di uno.

 sarà eseguito sempre e solo un backup, e mai più di uno.
Concordo, non fa una piega.
Dico una cosa banale, ma controlla che versione di rsync monti,
versioni vecchiotte ci mettono una vita ad indicizzare i files prima di 
partire, quelle nuove si scambiano l'"incremental file".
Così al volo, mi viene in mente un idea,
nel file di conf di rsnapshot c'è la possibilità di lanciare un comando
prima che venga eseguito l'rsync,
se ci metti uno scriptino che ti crea uno snapshot lvm per la durata del 
sync direi che non dovresti avere problemi di sovrapposizioni.
In ogni caso però se il daily ci mette 22 ore, rimane comunque uno 
strumento troppo lento.
-- Yena --

 strumento troppo lento.
22 ore la prima volta, auspico che gli incrementali successivi
non impieghino più di alcune ore.
Mi sa che faccio un wrapper di questo tipo per la rotazione:
---------------------------------------
rsnapshot sync
# Capodanno
if [ $(date '+%j') == '001' ]; then
    rsnapshot yearly
    exit
if
# Primo giorno del mese
if [ $(date '+%d') == '01' ]; then
    rsnapshot monthly
    exit
if
# Domenica (ultimo giorno settimana)
if [ $(date '+%u') == '7' ]; then
    rsnapshot weekly
    exit
if
# tutti gli altri casi
rsnapshot daily
-----------------------------------------
Può avere senso o mi perdo pezzi di backup?
Mi pare strano che rsnapshot di suo faccia
in maniera diversa arrivando a fare, in configurazioni
più o meno standard, 5 backup per la stessa cosa
suggerendo di fare incrementi anche di mezzora.
Un motivo ci deve pur essere....


 al weekly (che magari ha eseguito mezzora prima).
Correggo la frase:
In teoria, lui prima fa il daily, poi parte con il weekly.
Visto che è tutto incrementale, il weekly dovrebbe essere
di dimensioni microscopiche, perchè contenente solo i file
scritti rispetto al daily (che magari ha eseguito mezzora prima).


 weekly quando lo eseguo?
AFAICT il weekly non fa un backup ma è solo un job di "rotazione" che
prende l'ultimo daily e lo trasforma in weekly. Stessa cosa avviene per
monthly e yearly.
Leggi la documentazione, dovrebbe esserci scritto.
Backup levels must be specified in the config file in order, from most
frequent to least frequent. The first entry is the one which will be
synced with the backup points. The subsequent backup levels (e.g.,
daily, weekly, etc) simply rotate, with each higher backup level pulling
from the one below it for its .0 directory.
Example:
        retain  hourly 6
        retain  daily  7
        retain  weekly 4
daily.0/ will be copied from hourly.5/, and weekly.0/ will be copied
from daily.6/
hourly.0/ will be rsynced directly from the filesystem.
-- 
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.


Si confermo
-- Yena --

 uno per ciascun utente (600) che accedono al fileserver.
Devi fare un Upgrade a quella con la 2.6.8, vedrai grandi miglioramenti.
la 3.0.7 va già bene.
Fatto questo prova, secondo me ti dovrebbe risolvere il problema.
-- Yena --

 monthly e yearly.
Si si, hai ragione, confermo. Mi ero dimenticato di questo passaggio.
Io ho i backup in due fasi (non ricordo il nome esatto) tant'è che
devo fare prima il sync e poi la rotazione.
A sto punto uso il wrapper che ho postato poco fa con alcune
modifiche:
il sync lo fa sempre (è fuori dagli if)
terminato il sync, prosegue con il resto delle rotazioni.
il primo giorno dell'anno, faccio eseguire tutte le rotazioni, daily,
weekly, monthly, yearly.
il primo del mese, eseguo daily, weekly, monthly
e così via. In questo modo replico le funzionalità standard di
rsnapshot ma senza avere
il rischio che un backup troppo lungo mi faccia saltare la rotazione
per via del lock file.
Con il wrapper i comandi vengono eseguiti in seguenza (sul cron invece
no), quindi appena
termian il sync lui tira dritto, impiegando tutto il tempo necessario.

 Fatto questo prova, secondo me ti dovrebbe risolvere il problema.
Provare non costa nulla, ma sicuramente non risolve il problema.
Il mio problema, in questo caso, non è calcolare i file da trasferire,
bensì il trasferimento in se per se.
Facendo circa 600 backup distinti, il calcolo di ciascun backup è roba
da pochi minuti, 2-3 al massimo.

 esecuzione. (ma potrei sbagliarmi)
Attenzione, forse mi è sfuggito un particolare.
Le rotazioni vengono fatte in senso inverso, ovvero dalle più
'lontane' alle più recenti:
annuale
mensile
settimanale
giornaliero
tant'è che ogni 4 ore fa il sync + hourly, terminato il quale, se ci
fai caso, sia nel tuo cron che in quello di default, parte a ruotare
il mensile, poi mezzora dopo ruota il settimanale per poi arrivare al
giornaliero.
# 0 */4         * * *           root    /usr/bin/rsnapshot hourly
# 30 3          * * *           root    /usr/bin/rsnapshot daily
# 0  3          * * 1           root    /usr/bin/rsnapshot weekly
# 30 2          1 * *           root    /usr/bin/rsnapshot monthly
In questo caso il sync è implicito dentro l'hourly, ma tutti gli
altri, a guardare orario e minuti di esecuzione, sono in senso
inverso:
il mensile alle 2.30, il settimanale alle 3.00 il giornaliero alle
3.30
quindi sostanzialmente il wrapper che ho postato va messo in senso
inverso.

 bensì il trasferimento in se per se.
Ha terminato ora il secondo sync, incrementale rispetto a quello di
ieri.
Ha impiegato circa 1 ora e mezzo. Ottimo direi. Dalle 22-23 ore circa
siam
passati ad 1.30 ore.

 Non vorrei reinventare la ruota.
In teoria nemmeno io, ma e` quello che sto praticamente facendo... :/
Enrico

 uno per ciascun utente (600) che accedono al fileserver.
Perche` questa porcata? Ovvero, perche` non fare un backup unico di tutti e 
600 utenti?
Enrico

 informazioni non indifferente)?
Non gestisco ACL quindi non so.
Ma per quanto riguarda gli utenti, rsnapshot se li porta dietro
numerici, in questo modo tu avrai gli uid/gid corretti anche se non
associati ad alcuno username sulla macchina di backup. Quando fai il
restore, se gli utenti son presenti, saranno ripristinati, visto che
i uid/gid vengono mantenuti.
Tant'č che sul backup io ho utente 678, 679 etc etc che non
corrispondono a nulla, mentre sul server di origine si.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 600 utenti?
Non è una porcata, ho bisogno di 600 backup distinti e sopratutto
gli utenti devono poter accedere al backup liberamente.
Non tutti gli utenti hanno la stessa politica di retention.
Alcuni hanno un backup giornaliero mantenuto 2 volte, altri 7 e così via.
Altri avranno il backup orario, altri no. Etc etc etc.
Facendo 600 backup distinti (a partire dalla stessa share rsync) riesco
a gestire gli utenti come entità singole ed indipendenti.
In sostanza sul server da backuppare (attualmente è uno,
a regime saranno 6) ho una share rsync di nome "home" con dentro
i 600 utenti per server. (una normalissimo server multiutente)
Lato rsnapshot, ho un file di configurazione per ciascun utente
(generato da una mia procedura) che includono un file comune.
Nel file comune ci sono i settaggi di rsnapshot, nel file per-utente
ci sono le politiche di retention, la base dir dello snapshot e le
directory da backuppare (una sola)
Ad esempio:
# cat /etc/rsnapshot.d/utente1.conf
include_conf    /etc/rsnapshot.d/standard-retention.conf
snapshot_root   /var/snapshots/utente1/
logfile         /var/log/rsnapshot/utente1.log
backup          rsync://rsna...@xxx.xxx.xxx.xxx/home/utente1/*     ./
La share /home/ esporta tutta la directory home, ma io copio solo
il contenuto della directory utente.
Tutto ciò, dalle 600 alle 900 volte per ciascun server.
Ho potenzialmente 900 backup distinti a partire da una singola 
configurazione.
standard-rention.conf contiene la politica di retention standard
ed a sua volta include la config base di rsnapshot.
Gli utenti con policy particolari includeranno il file rispettivo.
A dire il vero, uso rsnapshot solo per pigrizia, non avevo voglia
di farmi il rotate dei backup, ma alla fine di rsnapshot è rimasto
poco, ho letteralmente decine di wrapper e script di avvio che lo
circondano, visto che la configurazione utente e l'elenco degli
stessi vengono ricalcolate ad ogni passata prendendole da alcune
API interne (ad esempio per saltare il backup in caso di utenti
non più attivi o per cambiare le password di accesso alla share samba
che esporta il backup in base alla password di accesso agli altri 
servizi). In pratica a me serve solo l'rsync ed il "cp -al".
Un casino decisamente automatizzato, ma ammetto che funziona bene :)
Con il backup unico, non avrei alcun controllo sugli utenti.


 Altri avranno il backup orario, altri no. Etc etc etc.
Hai mai pensato di utilizzare backuppc al posto di rsnapshot?


 informazioni non indifferente)?
Salvo in 3 file l'output di:
# getent passwd
# getent shadow
# getent group
E li allego al backup, così come faccio per il partizionamento (sfdisk
-d) e per LVM (vgdisplay -v, pvdisplay -v)


 Hai mai pensato di utilizzare backuppc al posto di rsnapshot?
Si, lo uso per fare backup di altri apparati, ma per questo progetto
sarebbe fin troppo invasivo, poi il modo in cui salva ed organizza
i pool non mi piace. rsnapshot è trasparente, ciascun backup è
pienamente
usabile via samba (in read-only per ovvi motivi) ed alla fine con 1
ora di lavoro ho fatto tutto.

 # getent group
e perchè mai con getent? Un cat non ti basta?
Chiedo, son curioso.


Perché getent ti fa vedere tutti gli utenti/password/gruppi visti dal
sistema, ivi compresi quelli inclusi con altri sistemi di
autenticazione, come NIS o Samba (tutti quelli in /etc/nsswitch.conf).
In particolare con Samba getent consente di sapere a quale utente del
dominio Windows è associato un determinato id, cosa non conoscibile a
priori dato che dipende dalla configurazione specifica del samba locale.


 Salvo in 3 file l'output di:
Il tuo modo di operare mi lascia perplesso, ovvero in caso di disaster 
recovery (o di ripristino su di una macchina simile) come ripristino il 
tutto?
Enrico


In che senso? Le ACL sono ripristinate anche senza che al momento del
ripristino gli utenti siano esistenti dato che anch'esse si basano come
i permessi standard su uid/gid. Del loro ripristino si interessa
direttamente rsync.
Nel disaster recovery ripristini l'intero sistema, quindi comprendi
anche /etc/passwd e le iscrizioni a domini windows, quindi non sussiste
alcun problema.
Il problema può invece presentarsi nel momento di ripristini parziali su
altre macchine; in questo caso può essere necessario conoscere a quale
utente corrispondesse un determinato uid/gid sulla macchina sorgente per
poter ricreare i mapping corretti, attività comunque che può essere manuale.


 manuale.
Non saprei dire, personalmente non mi dispiacerebbe automatizzare questa 
attivita` in modo semplice e sicuro. Comunque sia, in tutto questo rimane 
comunque fuori il discorso dei backup relativi ad altri sistemi (database, 
LDAP, DNS...) ma, come ho appena detto, e` un altro discorso :)
Enrico
P.S. giusto a titolo informativo, per ora i backup me li gestisco in 
modalita` full via bsdtar (GNU tar su debian non supporta le ACL, il bug e` 
aperto dal 2004)

 Hai mai pensato di utilizzare backuppc al posto di rsnapshot?
Occhio che BackupPC non supporta le ACL
Enrico

 Occhio che BackupPC non supporta le ACL
Sì, lo so, ma non mi sembra che fosse nei requisiti.


 aperto dal 2004)
Io usavo star.
