README

0. INTRODUCTION

A disk based backup system based on btrfs and rsync. Inspired from rsbackup
(ZFS+FreeBSD+Rsync), see: 

http://forums.freebsd.org/showthread.php?p=71162

Snapshots are rotated using a mechanism similar to that of Mac OS X TimeMachine.

At the moment all the documentation is in Italian.

All the work is released under the GNU GPL version 3 or any later version.

btrbackup: a backup system based on btrfs and rsync.
Copyright (C) 2011 Enrico Cavalli <cavalli@cilea.it>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

1. INTRODUZIONE

btrbackup  è  un   sistema  di  backup  centralizzato   basato  su  snapshot
realizzati tramite rsync  e btrfs. Il sistema è composto  da tre componenti
fondamentali:

  - scheduler:  come dice  il nome stesso  lancia i job  di backup  ad orari
  prefissati

  - job-runner: lanciato  da schedulerm, serve per lanciare N  job di backup
  in parallelo

  -  single-backup: è  il comando  che si  occupa della  maggior parte  del
  lavoro. Invoca rsync collegandosi sulle macchine da backuppare come utente
  non  privilegiato. L'rsync  sulle  macchine viene  lanciato tramite  "sudo
  rsync": è infatti necessario avere i diritti di root per poter backuppare
  le informazioni.

Gli snapshot vengono  esposti via NFS in sola lettura  ai server che possono
quindi facilmente procedere ad un restore tramite semplice cp o anche rsync.

La politica  di retention  al momento  è a carico  di single-backup  che è
stato sviluppato  imitando TimeMachine di Mac  OS X (un backup  orario nelle
ultime ventiqattro ore, un backup giornaliero negli ultimi trenta giorni, un
backup  settimanale  oltre i  trena  giorni,  con  un  numero di  giorni  di
retention configurabile).

Limitazioni: al momento non è  stata presa in considerazione la possiblità
di  conservare   ACL  ed  extended  attributes   (probabilmente  non  ancora
implementati su btrfs).
rsync viene invocato con l'opzione --inplace per sfruttare al massimo la 
capacita' di cow di btrfs ed essere efficienti in termini di spazio occupato.
Si noti che cio' non consente l'uso di --sparse (le due opzioni sono in
conflitto).

2. CONSIDERAZIONI DI SICUREZZA

In un sistema  di backup di questo tipo si  può procedere essenzialmente in
due modi: o tramite pull dai server remoti verso il server di backup, oppure
tramite push dai server remoti verso il server centralizzato. Ogni soluzione
ha i suoi pro e i suoi  contro. Riteniamo tuttavia che la soluzione pull sia
la più valida e versatile.

2.1 SOLUZIONE PULL

2.1.1 PRO

 - Scheduling deciso in base alle condizioni del server di backup.

 - La chiave ssh usata da root sul server di backup può essere protetta con
 ssh agent.

 - Non è necessario distribuire client di backup

2.1.2 CONTRO

  -  Esiste una  sola chiave:  compromessa questa  si ha  accesso ai  server
  remoti (firewall  e tcpwrappers  permettendo ovviamente).  Conviene quindi
  proteggere la chiave con password e usare ssh-agent.

  - L'utente  non privilegiato  presente sulle  macchine da  backuppare deve
  avere  la possibilità  di lanciare  rsync  come root  (tramite sudo).  In
  pratica questo  utente è in  grado di  fare qualsiasi cosa  tramite rsync
  sulla macchina  da backuppare.  Questo è  l'unico punto  veramente debole
  della soluzione che merita futuri sviluppi.

  - Il client  da backuppare deve essere costantemente connesso  (non è una
  soluzione adatta per client mobili ad esempio).

2.2 SOLUZIONE PUSH

2.2.1 PRO
 
  - Una soluzione push può essere idonea anche per client mobili.

2.2.2 CONTRO

  - E' necessario distribuire client di backup da tenere aggiornati.

  - Il client deve girare con diritti  di root sul server di backup. Diventa
  quindi  complesso fare  in  modo  che i  backup  non siano  reciprocamente
  visibili.

  - L'unica  possibilità sarebbe  girare come  utente non  privilegiato sul
  server  di backup  e  utilizzare l'opzione  --fake-super  che però  porta
  problemi  di  portabilità e  su  btrfs  non  sono ancora  sviluppati  gli
  extended attributes necessari al funzionamento di questa opzione.

  - La modalità di backup con --fake-super pone poi una certa scomodità in
  fase di restore: diventerebbe necessario un client di restore opportuno.

3. DIPENDENZE

Il software è stato  sviluppato su Debian 6.0 e dipende  da rsync >= 3.0.7,
mutt,  debianutils (per  savelog), procmail  (per lockfile),  bash (recente,
senz'altro >=3), gawk.


4. INSTALLAZIONE

Scaricare il sistema di backup da http://????

4.1 Inizializzare il filesystem btrfs

Sul server di backup occorre innanzitutto inizializzare un filesystem btrfs.

Il filesystem  btrfs viene  inizializzato senza  opzioni particolari,  ma è
opportuno  montarlo con  le  opzioni  compress e  noatime  per questioni  di
occupazione spazio disco e performance.

# mkfs.btrfs /dev/sdb
# mkdir /btrbackup
# mount -o compress,noatime,nodiratime /dev/sdb /btrbackup

Aggiungere  la riga corrispondente in /etc/fstab

4.2 Generare una chiave per l'autenticazione sui server da backuppare

cd etc/ ssh-keygen  -t dsa -C btrbackup-key -f chiave.dsa

Copiare la  parte pubblica della  chiave nello script di  configurazione dei
client (vedi contrib/config-client.sh)

Se la chiave privata  viene protetta da una passphrase, dopo ogni reboot è
necessario attivare l'ssh-agent caricandovi la chiave in oggetto. Per farlo
lanciare bin/start-agent.sh

4.3 Configurazioni varie

Per impedire a mutt di salvare la  posta in uscita inserire la seguente riga
in .muttrc dell'utente root:

set record="/dev/null"

5. CONFIGURAZIONE DI UN SERVER DA BACKUPPARE

Sui server da  backuppare deve essere creato un utente  btrbackup in grado di
eseguire rsync come utente root (tramite sudo).

Il  server deve  accettare  connessioni  ssh dal  server  di  backup e  deve
accettare connessioni ssh autenticate con  la chiave generata in precedenza.
Si veda contrib/config-client.sh per  un esempio di configurazione. Adattare
in base alle proprie specifiche esigenze.

Lato  server  di   backup  viene  semplicemente  fatto   girare  il  comando
addserver.sh che  si occupa di  inizializzare il  filesystem di base  su cui
andranno i backup e crea le entry  in /etc/exports per esportare via nfs gli
snapshot (in  sola lettura) e i  file di configurazione per  i filesystem da
incluedere e  le eventuali esclusioni (in  lettura/scrittura, per consentire
personalizzazione autonoma di questi dati).

addserver.sh  accetta  tre   argomenti:  l'hostname  o  ip   del  server  da
backuppare,  il  nome  che  vogliamo  dare al  file  di  configurazione  del
server  (si  riflette  anche  sul   nome  della  directory  in  cui  vengono
creati  gli snapshot)  e  opzionalmente un  indirizzo  email per  notificare
all'amministratore del server l'esito dei backup.

6. NOTE SU INCLUSIONI ED ESCLUSIONI

Per quanto riguarda  gli include, si possono backuppare solo  certe parti di
macchina. Ad esempio inserendo in filesystems.conf

/etc/asterisk /usr/local

vengono backuppate quelle due sole directory.

Poiché single-backup invoca  rsync con l'opzione --files-from  e al comando
viene indicato come sorgente il ramo "/", ovvero

rsync --file-from=[...] btrbackup@$HOST:/ /destination

l'effetto  pratico è  che sotto  la directory  destinazione viene  comunque
ricreato il  percorso completo dei  file e  directory oggetto di  backup. Ad
esempio avremo:

/btrbackup/macchina/.work/etc/asterisk

Per questo è possibile aggiungere, mano a mano che lo si desidera, parti di
filesystem che si vogliono mettere sotto backup, senza problemi di struttura
dell'albero delle directory che viene a crearsi sotto /btrbackup/macchina/.

Per quanto riguarda le esclusioni (specificabili in excludes.conf), prestare
attenzione alla diversità delle due sintassi possibili:

voicemail/ voicemail/**

La  prima non  crea  nemmeno  la directory  voicemail,  la  seconda crea  la
directory sul  server di backup  ma dentro di  essa non viene  salvato alcun
contenuto. Tutto sta nel capire se  si vuole mantenere la struttura completa
sotto backup, eventaulmente senza contenuto.

Nel dubbio conviene usare la seconda specifica.

7. RESTORE E PARAMETRI CONFIGURABILI DAL CLIENT

Il client può montare via nfs (v3) il proprio ramo di snapshot e la propria
directory di configurazione. Consigliamo di inserire delle righe di questo tipo
in /etc/fstab:

backup_server:/btrbackup/backup_dir	/restore nfs	ro,noauto,vers=3 0 0

E' da considerare per il futuro NFSv4 ma per il momento non è chiaro come gestire
l'autenticazione e idmap.