backup2l återställningsverktyg

Procédure

backup2l

backup2l är ett kommandoradsverktyg för att skapa och återställa säkerhetskopior på ett fjärrbackupsystem. I en standardinstallation skapas säkerhetskopior autonomt av ett cron-skript.

backup2l stöder hierarkiska differentiella säkerhetskopior med ett användarspecificerat antal nivåer och säkerhetskopior per nivå. Med det här systemet ökar det totala antalet arkiv som ska lagras endast logaritmiskt med antalet differentiella säkerhetskopior sedan den senaste fullständiga säkerhetskopieringen. På så sätt kan små inkrementella säkerhetskopior genereras med korta intervall, samtidigt som det inte finns något behov av tids- och utrymmeskrävande fullständiga säkerhetskopior.

Återställningsfunktionen gör det enkelt att återställa filsystemets status eller godtyckliga kataloger/filer från tidigare tidpunkter. Ägar- och behörighetsattribut för filer och kataloger återställs på ett korrekt sätt.

En öppen drivrutinsarkitektur innebär att praktiskt taget alla arkiveringsprogram kan användas som backend. Inbyggda drivrutiner stöder .tar.gz-, .tar.bz2- eller .afioz-filer. Andra användardefinierade drivrutiner kan läggas till, vilket beskrivs i den medföljande konfigurationsfilen "first-time.conf".

Alla styrfiler lagras tillsammans med arkiven på fjärrbackupsystemet, och innehållet är vanligtvis självförklarande. I en nödsituation behöver en användare därför inte bara förlita sig på backup2ls återställningsfunktion, utan kan - om det behövs - bläddra bland filerna och extrahera arkiven manuellt.

För att avgöra om en fil är ny eller ändrad undersöker backup2l dess namn, ändringstid, storlek, ägarskap och behörigheter.

Det är också möjligt att utföra "Hot Copies", t.ex. av MySQL-databaser.

Installera backup2l

Ingår som ett paket med de flesta distributioner.

För att installera backup2l på din lokala maskin krävs ett enkelt kommando.

⌨ Kommando
apt-get installera backup2l

Konfigurera backup2l

Skapa dessa två mappar för säkerhetskopiering:

⌨ Kommando
$ mkdir -p /var/backup.d/final $ mkdir -p /var/backup.d/preliminary/mysql

Mappen "final" innehåller arkiven för de säkerhetskopior som har utförts och mappen "premilinary" innehåller de "heta kopiorna" av de säkerhetskopior som har utförts.

Redigera konfigurationsfilen för backup2, t.ex. med textredigeraren nano:

⌨ Kommando
$ nano /etc/backup2l.conf

På raden:

Kod
SRCLIST=(/var/www/mondomaine.fr /var/backup.d/preliminary)

Välj de mappar som du vill säkerhetskopiera. I det här exemplet kommer mapparna som säkerhetskopieras att vara: /var/www/mondomaine.fr och /var/backup.d/preliminary, som innehåller de "heta kopiorna".

⌨ Kommando
SKIPCOND=(-väg "/var/www/mondomaine.fr/log/*")

Eftersom utrymmet på säkerhetskopieringsmålet oftast är begränsat bör du utesluta större kataloger och filer som egentligen inte behöver säkerhetskopieras, t.ex. loggfilerna som är kopplade till din webbplats.

⌨ Kommando
BACKUP_DIR="/var/backup.d/final"

Säkerhetskopieringen konfigureras i den här katalogen. Filerna här överförs sedan till backupservern. Vid behov kan filerna även krypteras.

⌨ Kommando
MAX_LEVEL=1 MAX_PER_LEVEL=9 MAX_FULL=1 GENERATIONS=1 CREATE_CHECK_FILE=1

Den här konfigurationen ger en fullständig säkerhetskopia och 9 inkrementella säkerhetskopior. Om en ny inkrementell säkerhetskopia ska göras varje vecka bör max_per_level ställas in på 6. En fullständig säkerhetskopia och de inkrementella säkerhetskopiorna är alltid nödvändiga för en återställning.

⌨ Kommando
PRE_BACKUP () { echo "start pre backup scripts" sh /root/backup/hotcopy_mysql.sh chmod -R u=rw,go-rwx /var/backup.d/preliminary/* echo "pre backup scripts completed" }

⌨ Kommando
POST_BACKUP () { echo "Utför åtgärder efter säkerhetskopiering." chown -R root:backup /var/backup.d/final chmod -R u=rw,g=r /var/backup.d/final/* sh /root/backup/scp.sh echo "Säkerhetskopieringen har slutförts." echo "----------------------------------------------" }

Dessa funktioner implementeras före och/eller efter säkerhetskopieringen.

I det här avsnittet körs funktionen "PRE_BACKUP()" före säkerhetskopieringen och funktionen "POST_BACKUP()" körs efter säkerhetskopieringen. Bash-skriptet /root/backup/scp.sh för uppladdning av säkerhetskopian läggs till funktionen "POST_BACKUP()".

Din backup2l.conf-fil är nu konfigurerad, så att backup2l kan ta hänsyn till din konfiguration, redigera detta direktiv enligt följande:

⌨ Kommando
UNCONFIGURED=0

Göra "heta kopior

Vissa filer kan inte helt enkelt säkerhetskopieras genom kopiering, eftersom de är ständigt tillgängliga. Till exempel MySQL-databaser.

  • MySQL
⌨ Kommando
nano /root/backup/hotcopy_mysql.sh

Här används programmet "mysqldump" för att göra säkerhetskopior av data i våra MySQL-databaser.

⌨ Kommando
#!/bin/sh # Ta bort gamla dumpar och skapa katalog rm /var/backup.d/preliminary/mysql/alldb.sql.gz mysqldump --user=root --password=XXXXX --all-databases --skip-lock-tables | gzip > /var/backup.d/preliminary/mysql/alldb.sql.gz

Konfigurera cron-jobbet

För att göra detta konfigurerar du filen /etc/cron.daily/zz-backup2l med följande innehåll (den här filen kan redan ha konfigurerats när backup2l installerades)

⌨ Kommando
#!/bin/bash # Följande kommando anropar 'backup2l' med standardkonfigurationsfilen # (/etc/backup2l.conf). # # (Flytta) den eller hela skriptet om du inte vill ha automatiska säkerhetskopior. # # Omdirigera dess utdata om du inte vill ha automatiska e-postmeddelanden efter varje säkerhetskopia. ! which backup2l > /dev/null || nice -n 19 backup2l -b

Filöverföring

Det finns i allmänhet två sätt att återställa filer från backupservern. Det första och mest troliga alternativet är att kopiera från den server där säkerhetskopieringen gjordes till målservern (backup-servern): Tryck på data. Detta kan till exempel göras med scp. Det andra alternativet är data från backupservern, återigen med hjälp av scp: Pull Data. Det sista alternativet är enligt min mening att föredra eftersom en hackare inte bara kan komma åt säkerhetskopiorna.

För båda alternativen rekommenderar jag att du använder scp, eftersom backupservern förmodligen ändå har en SSH-inloggning och prestanda inte bör vara en faktor med en enda kopia på natten. Dessutom är överföringen krypterad. Du kan också använda rsync.

Filer kan också krypteras med gpg och endast överföras krypterade. Data på backup-servern är då skyddad från obehöriga tredje parter. Dekrypteringsnyckeln ska inte lämnas på en server utan kopieras lokalt till ett flyttbart lagringsmedium, t.ex. ett USB-minne.

Skapa en SSH-nyckel och bifoga den till backupservern. Jag uppmanar dig att följa denna dokumentation för att lägga till en SSH-nyckel till backupservern.

⌨ Kommando
$ ssh-keygen -b 4096 -t rsa

Skapa sedan ett bash-skript för säkerhetskopiering i /root/backup

⌨ Kommando
nano /root/backup/scp.sh

För att ordna kommandona kommer verktyget "rsyncscpdrive" under namnet cdXXXX att användas som ett exempel.

⌨ Kommando
#!/bin/bash SOURCE_DIRECTORY=/var/backup.d/final USER=cdXXXX TARGET_DIRECTORY=/files SERVER=rs1.cloudlws.com scp ${SOURCE_DIRECTORY}/* ${USER}@${SERVER}:${TARGET_DIRECTORY}

Sammanfattning av de tillgängliga LWS Cloud Drive-paketen och deras priser exklusive moms:

Månadspriser för Cloud Drive-paket :
Cloud Drive S
Cloud Drive M
Cloud Drive L
Cloud Drive XL
100 GB 250 GB 500 GB 1TB
4.99€* 9.99€* 14.99€* 19.99€*

*Pris exkl. moms

Genom att följa denna dokumentation kommer du att kunna använda backup2l-verktyget för att återställa dina data.
Du kan ta del av våra olika erbjudanden om onlinebackup på vår försäljningssida.

help.lws.net/a/1238
Var den här artikeln till hjälp?

Ja

Nej

Läst 13 391 gånger

Tack! Ställ gärna frågor om vår dokumentation om du vill ha mer information och hjälp oss att förbättra den.

Liknande artiklar

En fråga om den här artikeln?

Ställ den till LWS-teamet och communityn. Svaret publiceras efter moderering.

Ställ en fråga till AWS-teamet och dess community

GDPR: Personuppgiftsansvarig: LWS-Ligne Web Services. Ändamål: moderering och offentlig publicering av din fråga, eventuellt meddelande om ett svar. Rättslig grund: samtycke (art. 6.1 a GDPR). Lagring av e-postadresser: 90 dagar efter meddelandet, högst 12 månader utan svar. För att utöva dina rättigheter, se GDPR-avsnittet i våra allmänna villkor.