Costruzione per la Produzione: Applicazioni Web — Backup

Introduzione

Dopo aver ideato un piano di recupero per i vari componenti dell’applicazione, dovresti impostare il sistema di backup richiesto per supportarlo. Questo tutorial si concentrerà sull’uso di Bacula come soluzione di backup. I benefici dell’uso di un sistema di backup completo, come Bacula, sono che ti dà il pieno controllo su ciò che si fa il backup e la ripristinazione a livello di file individuale, e puoi pianificare il backup e il ripristino in base a ciò che è migliore per te.

Soluzioni come DigitalOcean Droplet Backups (backup di snapshot dell’intero Droplet) sono facili da configurare e potrebbero essere sufficienti per le tue necessità, se richiedi solo backup settimanali. Se opti per DigitalOcean Backups, assicurati di impostare i backup caldi del database seguendo la sezione Create Hot Backups of Your Database.

In questa parte del tutorial, configurerremo Bacula per mantenere i backup giornalieri delle backup necessarie dei server che compongono la nostra configurazione applicativa (db1, app1, app2 e lb1), definite precedentemente nel nostro piano di recupero – in pratica, questo è un tutorial che vi mostra come utilizzare Bacula per creare backup di un stack LAMP. Anche qui, userremo Percona XtraBackup per creare backup hot del database MySQL. Infine, userremo rsync per creare una copia dei nostri backup su un server in un data center remoto. Questo aggiungerà due server al nostro setup: backups e remotebackups ( situati in un data center separato).

Cominciamo.

Installare Bacula sul server di backup

Configurare Bacula sul tuo server backups seguendo questo tutorial: Come installare il server di Bacula su Ubuntu 14.04.

Per organizzare la configurazione di Bacula Director (server), seguire la sezione Organize Bacula Director Configuration (Server) del tutorial: Come fare il backup di un server Ubuntu 14.04 con Bacula. Necessiterai del nome del direttore quando si setta up i client di Bacula (sui server che vuoi salvare). Fermatevi quando arrivate alla sezione Install and Configure Bacula Client. Nota che utilizzeriamo il pool RemoteFile per tutti i job di backup che avremmo impostato. Dichiarati questo, potreste voler cambiare alcune impostazioni prima di procedere.

Install Bacula Client on Each Server

Install the Bacula client on each server you want to back up (db1, app1, app2, and lb1) by following the Install and Configure Bacula Client section of this tutorial: How To Back Up an Ubuntu 14.04 Server with Bacula. Stop when you reach the Add Filesets (Server) section.

Nota che avrai bisogno del FileDaemon Name (di solito il nome host concatenato da “-fd”) e del Director Password (la password che il server Bacula userà per connettersi a ciascun client) dall’file bacula-fd.conf su ogni server.

Aggiungi Client Bacula al Server di Backup

Su backups, il server Bacula, aggiungi una risorsa Client all’file /etc/bacula/conf.d/clients.conf per ogni server su cui hai installato il client Bacula.

Apri l’file clients.conf:

  1. sudo vi /etc/bacula/conf.d/clients.conf

Ecco un esempio della definizione della risorsa Client per il server database db1. Notare che il valore di Name deve corrispondere al nome della risorsa FileDaemon e il Password deve corrispondere alla Password della risorsa Director, sul server client— questi valori possono essere trovati in /etc/bacula/bacula-fd.conf su ogni server client Bacula:

clients.conf — Example Client resource definition
Client {
  Name = db1-fd
  Address = db1.nyc3.example.com
  FDPort = 9102
  Catalog = MyCatalog
  Password = "PDL47XPnjI0QzRpZVJKCDJ_xqlMOp4k46"          # password for Remote FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

Creare una risorsa Client simile per ognuno degli altri server client Bacula rimasti. Nel nostro esempio, dovrebbe esserci quattro risorse Client quando sarai finito: db1-fd, app1-fd, app2-fd, e lb1-fd. Questa configura il Director Bacula, sul server backups, in modo da poter connettersi al client Bacula su ciascun server…

Salva e uscita.

Più dettagli sul segmento sono disponibili nel Guida all’installazione e configurazione di Bacula Client nell’tutorial How To Back Up an Ubuntu Server with Bacula.

Fai un’immagine di backup calda del database

Per assicurarsi che le nostre copie di backup siano coerenti (ovvero utilizzabili), è necessario prendere precauzioni speciali. Un modo semplice ed efficace per creare i backup caldi con MySQL è l’uso di Percona XtraBackup.

Installa Percona XtraBackup

Nel tuo server del database, db1, installa e configura Percona XtraBackup seguendo questo tutorial: Come fare le immagini di backup calde dei database MySQL con Percona XtraBackup su Ubuntu 14.04. Fermati quando arrivate al segmento Perform Full Hot Backup.

Creare un script di Bash per XtraBackup

È ora di creare i backup caldi del tuo database MySQL con XtraBackup, che saranno poi archiviati da Bacula (o DigitalOcean Backups). Tuttavia, i backup caldi devono essere pianificati in alcune maniera. Si imposterà la soluzione più semplice: un script Bash e un’operazione cronJob.

Crea un script Bash chiamato run_extra_backup.sh nel directory /usr/local/bin:

  1. sudo vi /usr/local/bin/run_xtrabackup.sh

Aggiungi il seguente script. E sicuro sostituire l’utente e la password con quelle che hai impostato quando hai installato XtraBackup:

/usr/local/bin/run_xtrabackup.sh
#!/bin/bash

# prima di xtrabackup
chown -R mysql: /var/lib/mysql
find /var/lib/mysql -type d -exec chmod 770 "{}" \;

# elimina il backup completo precedente
rm -r /data/backups/full

# xtrabackup create backup
innobackupex --user=bkpuser  --password=bkppassword --no-timestamp /data/backups/full

# xtrabackup prepare backup
innobackupex --apply-log /data/backups/full

Salva e uscita. Eseguendo questo script (con privilegi di superutente) cancellerà il backup esistente di XtraBackup su /data/backups/full e creerà un nuovo backup completo. Più dettagli sulle creazioni dei backup caldi con XtraBackup si possono trovare nella sezione Effettuare il backup caldo completo del tutorial di XtraBackup.

Rendi il script eseguibile:

  1. sudo chmod +x /usr/local/bin/run_xtrabackup.sh

Per eseguire correttamente il backup del nostro database, abbiamo bisogno di eseguire prima lo script XtraBackup quando Bacula tenta di fare il backup del server del database. Un’ottima soluzione è configurare i tuoi job di backup di Bacula per eseguire lo script come “pre-backup script”, ma optiamo per usare un cron job per mantenerlo semplice.

Creare una configurazione cron (i file in /etc/cron.d vengono aggiunti al crontab dell’utente root):

  1. sudo vi /etc/cron.d/xtrabackup

Aggiungere il seguente job cron:

/etc/cron.d/xtrabackup
30 22    * * *   root    /usr/local/bin/run_xtrabackup.sh

Questo pianifica l’esecuzione dello script ogni giorno alle 22:30 (ora 22, minuto 30). Scegliemmo questo tempo perché Bacula è attualmente programmato ad eseguire i suoi job di backup quotidiani alle 23:05 – abbiamo scelto questo tempo per consentire 35 minuti allo script XtraBackup di completarsi. Questo permette anche ai backup hot del database di funzionare correttamente. Ora guardiamo le FileSets di backup di Bacula.

Configura i FileSets di Bacula

Bacula creerà i backup dei file specificati nei FileSet associati ai Job di backup che saranno eseguiti. Questa sezione ti guiderà nel creare i FileSet che includono i backup richiesti che abbiamo identificato nelle nostre pianificate di ripristino. Più dettagli su come aggiungere FileSet a Bacula si trovano nella sezione Aggiungi FileSet (Server) del tutorial di Bacula.

Nell’ambiente del tuo server di backup, apri il file filesets.conf.

  1. sudo vi /etc/bacula/conf.d/filesets.conf

FileSet per il server applicazioni

I backup necessari per il server applicativo, secondo il piano di ripristino del server applicativo, includono:

  • MysQL database: creato un backup copia da parte del nostro script XtraBackup alle ore 22:30 ogni giorno
  • Configurazione MySQL: situata in /etc/mysql

Tramite anche il script XtraBackup: /usr/local/bin/run_xtrabackup.sh, e il relativo file cron.

Con i backup richiesti in mente, aggiungerai questo “FileSet MySQL Database” alla configurazione di Bacula:

filesets.conf — MySQL Database
FileSet {
  Name = "MySQL Database"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /data/backups
    File = /etc/mysql/my.cnf
    File = /usr/local/bin/run_xtrabackup.sh
    File = /etc/cron.d/xtrabackup
  }
  Exclude {
    File = /data/backups/exclude
  }
}

Ora passiamo al FileSet dell’applicazione server.

FileSet dell’Applicazione Server

Le copie di backup necessarie per i nostri server di applicazione, secondo il nostro piano di recupero del server di applicazione, comprendono:

  • File dell’applicazione: situati in /var/www/html nell’esempio nostro

Con le nostre copie di backup richieste in mente, aggiorneremo questo FileSet “DocumentRoot di Apache” alla nostra configurazione Bacula:

filesets.conf — Apache DocumentRoot
FileSet {
  Name = "Apache DocumentRoot"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /var/www/html
  }
  Exclude {
    File = /var/www/html/exclude
  }
}

Potreste anche includere il file di configurazione delle porte Apache, ma questo è facilmente sostituibile.

Adesso passiamo al FileSet del server di load balancer.

FileSet del Server Load Balancer

Le copie di backup necessarie per i nostri server di load balancer, secondo il nostro piano di recupero del server di load balancer, comprendono:

  • Certificato SSL (PEM) e file correlati: situati in /root/certs nell’esempio nostro
  • File di configurazione di HAProxy: situati in /etc/haproxy

Con le nostre copie di backup richieste in mente, aggiorneremo questo FileSet “DocumentRoot di Apache” alla nostra configurazione Bacula:

filesets.conf — SSL Certs and HAProxy Config
FileSet {
  Name = "SSL Certs and HAProxy Config"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /root/certs
    File = /etc/haproxy
  }
  Exclude {
    File = /root/exclude
  }
}

Salva e uscire.

Ora abbiamo configurato i nostri FileSets. Passiamo ad creare iJob di backup di Bacula che utilizzeranno questi FileSets.

Creazione dei Job di backup di Bacula

Creiamo iJob di backup di Bacula che usaranno i nostri server.

Crea un file jobs.conf in /etc/bacula/conf.d:

  1. sudo vi /etc/bacula/conf.d/jobs.conf

Backup Job per il Server di Database

Per il backup del server di database, creiamo un nuovo job chiamato “Backup_db1”. Importante è specificare correttamente il Client (db1-fd) e FileSet (MySQL Database):

jobs.conf — Backup db1
Job {
  Name = "Backup db1"
  JobDefs = "DefaultJob"
  Client = db1-fd
  Pool = RemoteFile
  FileSet="MySQL Database"
}

Ora organizziamo iJob di backup per i servizi applicativi.

Backup Jobs per i Servizi Applicativi

Per i nostri server applicativi, creiamo due job di backup chiamati “Backup app1” e “Backup app2”. Importante è specificare correttamente i Clients (app1-fd e app2-fd) e FileSet (Root documentale Apache).

Job di app1:

jobs.conf — Backup app1
Job {
  Name = "Backup app1"
  JobDefs = "DefaultJob"
  Client = app1-fd
  Pool = RemoteFile
  FileSet="Apache DocumentRoot"
}

Aggiorno il job:

jobs.conf — Backup app2
Job {
  Name = "Backup app2"
  JobDefs = "DefaultJob"
  Client = app2-fd
  Pool = RemoteFile
  FileSet="Apache DocumentRoot"
}

Ora impostare il job di riserva del server di bilancio.

Job di riserva per il server di bilancio

Per il nostro job di riserva del server di bilancio, creiamo un nuovo job chiamato “Backup lb1”. L’elemento importante è specificare correttamente il Client (lb1-fd) e il FileSet (SSL Certs e HAProxy Config):Client (lb1-fd) e FileSet (SSL Certs e HAProxy Config).

jobs.conf — Backup lb1
Job {
  Name = "Backup lb1"
  JobDefs = "DefaultJob"
  Client = lb1-fd
  Pool = RemoteFile
  FileSet="SSL Certs and HAProxy Config"
}

Salva e esiti.

Ora i nostri job di backup sono configurati. L’ultimo passaggio è riavviare il direttore di Bacula.

Riavviare il direttore di Bacula

Nel server di backups , riavviare il direttore di Bacula per applicare tutte le modifiche effettuate:

  1. sudo service bacula-director restart

Al questo punto, vuoi probare le tue connessioni client e i job di backup, che sono coperti nel tutorial su come fare un’estrazione di server con Bacula. Questo tutorial anche copre come ripristinare i backup di Bacula. Nota che il ripristino del database MySQL richiederà di seguire la step Perform Backup Restoration del tutorial su Percona XtraBackup.

Rivista schede di backup

La scheda di backup di Bacula può essere modificata modificando la configurazione del Bacula Director (/etc/bacula/bacula-dir.conf). Tutti i Job creati usano il JobDef “DefaultJob”, che usa la “WeeklyCycle” scheda, definita come:

  • Full backup on the first Sunday of a month at 11:05 pm
  • Differential backups on all other Sundays at 11:05 pm
  • Incremental backups on other days, Monday through Saturday, at at 11:05 pm

Puoi verificarlo usando la console Bacula per controllare lo stato dei tuoi Job: dovrebbe mostrare tutti i tuoi job pianificati:

Director Status — Scheduled Jobs
Scheduled Jobs: Level Type Pri Scheduled Name Volume =================================================================================== Incremental Backup 10 20-May-15 23:05 BackupLocalFiles MyVolume Incremental Backup 10 20-May-15 23:05 Backup lb1 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup app2 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup app1 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup db1 Remote-0002

Scegli liberamente il calendario di qualsiasi job di backup. E soprattutto sensibile modificare la pianificazione dei server applicativi per coincidere con l’esecuzione del script Percona XtraBackup (10:30 pm). Ci servira evitare che i backup dell’applicazione e del database si siano trovati in conflitto con l’altro.

Impostare le copie di backup remoti

Ora siamo pronti a impostare un server remoto che sarà utilizzato per archiviare le copie dei backup di Bacula. Questo server remoto deve essere situato in una regione geograficamente separata dall’area dati di produzione, così avrai una copia di backup crittate anche se c’è un disastro nel centro dati di produzione. Nell’esempio usaremo la regione di San Francisco (SFO1) di DigitalOcean come nostro serverremotobackups.

Verranno spiegati semplici metodi per inviare i backup dal nostro serverbackups al serverremotobackups usando chiavi pubbliche SSH, rsync e cron.

Nel serverremotobackups crea un utente che verrà usato per il login rsync.

Successivamente, su il servizio di backup, genera un coppia di chiavi SSH senza password come root. Installa la chiava pubblica sul tuo account utente creato recentemente. Questo è coperto nel nostro tutorial su come impostare le chiavi SSH.

Nel server di backup, scrivi un comando rsync che copii i dati di backup di Bacula (/bacula/backup) su qualche luogo sul server di remotebackups. L’uso dell’rsync è coperto nel nostro tutorial su come usare rsync. Il comando probabilmente avrà un aspetto simile a questo:

  1. rsync -az /bacula/backup remoteuser@remotebackups_public_hostname_or_IP:/path/to/remote/backup

Aggiungi il comando al file di script, ad esempio /usr/local/bin/rsync_backups.sh e rendere il file eseguibile.

Ultimo passaggio, vuoi impostare un job cron che esegue il rsync_backups.sh come root dopo che i job di backup di Bacula generalmente completano. Ciò è coperto nel nostro tutorial su come pianificare routine task con cron.

Dopo aver impostato tutto questo, verifica che ci siano copie dei tuoi backup sul server di remotebackups il giorno successivo.

Altri considerazioni

Non abbiamo discusso le richieste di spazio su disco per i tuoi backup. Devi certamente rivedere quanto spazio occupano i tuoi backup e rivisitare la tua configurazione e il pianificatore di backup in base ai tuoi bisogni e alle risorse disponibili.

Oltre a creare i backup dei tuoi server applicativi, probabilmente vuoi impostare i backup per qualsiasi altro server che vi sia aggiunto al tuo setup. Ad esempio, dovrai configurare Bacula per creare i backup dei server di monitoraggio e di log centralizzati una volta che li avviate.

Conclusione

Ora hai i backup giornalieri e una copia remota di questi backup sul tuo server di produzione. Assicurati di verificare che sia in grado di ripristinare i file e aggiungi le step di ripristino ai piani di recupero.

Prosegui all’ultimo tutorial per iniziare a impostare il monitoraggio per la tua configurazione server di produzione: Building for Production: Web Applications — Monitoring.

Source:
https://www.digitalocean.com/community/tutorials/building-for-production-web-applications-backups