sql >> Databasteknik >  >> NoSQL >> MongoDB

Tips för att lagra MongoDB-säkerhetskopior i molnet

När det kommer till säkerhetskopiering och dataarkivering är IT-avdelningar under press att uppfylla strängare servicenivåavtal, leverera fler anpassade rapporter och följa utökade efterlevnadskrav samtidigt som de fortsätter att hantera dagliga arkiverings- och säkerhetskopieringsuppgifter. Utan tvekan lagrar databasserver en del av ditt företags mest värdefulla information. Att garantera tillförlitliga säkerhetskopior av databas för att förhindra dataförlust i händelse av en olycka eller maskinvarufel är en kritisk kryssruta.

Men hur gör man det till verkligt DR när all din data finns i ett enda datacenter eller till och med datacenter som är nära geolokaliseringen? Dessutom, oavsett om det är en högbelastad server dygnet runt, eller en miljö med låga transaktionsvolymer, kommer du att behöva göra säkerhetskopior till en sömlös procedur utan att störa serverns prestanda i en produktionsmiljö.

I den här bloggen kommer vi att granska MongoDB backup till molnet. Molnet har förändrat säkerhetskopieringsbranschen. På grund av dess överkomliga pris har mindre företag en extern lösning som säkerhetskopierar all deras data.

Vi kommer att visa dig hur du utför säkra MongoDB-säkerhetskopior med hjälp av mongo-tjänster samt andra metoder som du kan använda för att utöka dina alternativ för återställning av databaskatastrofer.

Om din server eller backupdestination är belägen i en exponerad infrastruktur som ett offentligt moln, värdleverantör eller ansluten via ett opålitligt WAN-nätverk, måste du tänka på ytterligare åtgärder i din säkerhetskopieringspolicy. Det finns några olika sätt att utföra säkerhetskopiering av databas för MongoDB, och beroende på typen av säkerhetskopiering kommer återställningstid, storlek och infrastrukturalternativ att variera. Eftersom många av molnlagringslösningarna helt enkelt är lagring med olika API-gränssnitt, kan vilken backuplösning som helst utföras med lite skript. Så vilka alternativ har vi för att göra processen smidig och säker?

MongoDB Backup Encryption

Säkerhet bör stå i centrum för alla åtgärder som IT-team gör. Det är alltid en bra idé att upprätthålla kryptering för att förbättra säkerheten för säkerhetskopierade data. Ett enkelt användningsfall för att implementera kryptering är där du vill överföra säkerhetskopian till ett externt backup-lagringsutrymme i det offentliga molnet.

När du skapar en krypterad säkerhetskopia är en sak att tänka på att det vanligtvis tar längre tid att återställa. Säkerhetskopieringen måste dekrypteras innan återställningsaktiviteter. Med en stor datauppsättning kan detta leda till vissa förseningar för RTO.

Å andra sidan, om du använder de privata nycklarna för kryptering, se till att förvara nyckeln på ett säkert ställe. Om den privata nyckeln saknas kommer säkerhetskopian att vara värdelös och omöjlig att återställa. Om nyckeln blir stulen kommer alla skapade säkerhetskopior som använder samma nyckel att äventyras eftersom de inte längre är säkrade. Du kan använda populära GnuPG eller OpenSSL för att generera privata eller publika nycklar.

För att utföra MongoDBdump-kryptering med GnuPG, generera en privat nyckel och följ guiden i enlighet med detta:

$ gpg --gen-key

Skapa en vanlig MongoDBdump-säkerhetskopia som vanligt:

$ mongodump –db db1 –gzip –archive=/tmp/db1.tar.gz
Kryptera dumpfilen och ta bort den äldre vanliga säkerhetskopian:
$ gpg --encrypt -r ‘[email protected]’ db1.tar.gz

$ rm -f db1.tar.gz
GnuPG kommer automatiskt att lägga till .gpg-tillägget på den krypterade filen. För att dekryptera

kör helt enkelt gpg-kommandot med --decrypt flagga:

$ gpg --output db1.tar.gz --decrypt db1.tar.gz.gpg
För att skapa en krypterad MongoDBdump med OpenSSL måste man generera en privat nyckel och en publik nyckel:
OpenSSL req -x509 -nodes -newkey rsa:2048 -keyout dump.priv.pem -out dump.pub.pem

Denna privata nyckel (dump.priv.pem) måste förvaras på en säker plats för framtida dekryptering. För Mongodump kan en krypterad säkerhetskopia skapas genom att skicka innehållet till openssl, till exempel

mongodump –db db1 –gzip –archive=/tmp/db1.tar.gz | openssl smime -encrypt -binary -text -aes256

-out database.sql.enc -outform DER dump.pub.pem
För att dekryptera, använd helt enkelt den privata nyckeln (dump.priv.pem) bredvid flaggan -decrypt:

openssl smime -decrypt -in database.sql.enc -binary -inform

DEM -inkey dump.priv.pem -out db1.tar.gz

MongoDB Backup Compression

Inom databasens molnsäkerhetsvärld är komprimering en av dina bästa vänner. Det kan inte bara spara lagringsutrymme, utan det kan också avsevärt minska tiden som krävs för att ladda ner/ladda upp data.

Förutom arkivering har vi även lagt till stöd för komprimering med gzip. Detta avslöjas genom introduktionen av ett nytt kommandoradsalternativ "--gzip" i både mongodump och mongorestore. Komprimering fungerar både för säkerhetskopior skapade med katalogen och arkivläget och minskar diskutrymmesanvändningen.

Normalt kan MongoDB dump ha de bästa komprimeringshastigheterna eftersom det är en platt textfil. Beroende på komprimeringsverktyget och förhållandet kan en komprimerad MongoDBdump vara upp till 6 gånger mindre än den ursprungliga säkerhetskopieringsstorleken. För att komprimera säkerhetskopian kan du skicka MongoDBdump-utgången till ett komprimeringsverktyg och omdirigera den till en målfil

Om du har en komprimerad säkerhetskopia kan du spara upp till 50 % av den ursprungliga säkerhetskopians storlek, beroende på datauppsättningen.

mongodump --db country --gzip --archive=country.archive

Begränsa nätverkets genomströmning

Ett bra alternativ för molnsäkerhetskopiering är att begränsa bandbredden för nätverksströmning (Mb/s) när du säkerhetskopierar. Det kan du uppnå med pv-verktyget. Pv-verktyget kommer med alternativ för datamodifierare -L RATE, --rate-limit RATE som begränsar överföringen till maximalt RATE-byte per sekund. Nedan exempel kommer att begränsa den till 2MB/s.

$ pv -q -L 2m

Överföra MongoDB-säkerhetskopior till molnet

När din säkerhetskopia nu är komprimerad och säker (krypterad) är den redo för överföring.

Google Cloud

Kommandoradsverktyget gsutil används för att hantera, övervaka och använda dina lagringshinkar på Google Cloud Storage. Om du redan har installerat gcloud util, har du redan gsutil installerat. Annars följer du instruktionerna för din Linux-distribution härifrån.

För att installera gcloud CLI kan du följa proceduren nedan:

curl https://sdk.cloud.google.com | bash
Starta om ditt skal:
exec -l $SHELL
Kör gcloud init för att initiera gcloud-miljön:
gcloud init
Med kommandoradsverktyget gsutil installerat och autentiserat, skapa en regional lagringshink med namnet MongoDB-backups-storage i ditt nuvarande projekt.
gsutil mb -c regional -l europe-west1 gs://severalnines-storage/

Creating gs://MongoDB-backups-storage/

Amazon S3

Om du inte använder RDS för att vara värd för dina databaser, är det mycket troligt att du gör dina egna säkerhetskopior. Amazons AWS-plattform, S3 (Amazon Simple Storage Service) är en datalagringstjänst som kan användas för att lagra säkerhetskopior av databas eller andra affärskritiska filer. Antingen är det Amazon EC2-instans eller din lokala miljö så kan du använda tjänsten för att säkra din data.

Medan säkerhetskopior kan laddas upp via webbgränssnittet, kan det dedikerade kommandoradsgränssnittet s3 användas för att göra det från kommandoraden och genom skript för säkerhetskopiering. Om säkerhetskopior ska sparas under mycket lång tid, och återställningstiden inte är ett problem, kan säkerhetskopior överföras till Amazon Glacier-tjänsten, vilket ger mycket billigare långtidslagring. Filer (amazonobjekt) lagras logiskt i en stor platt behållare som heter hink. S3 presenterar ett REST-gränssnitt till sina interna enheter. Du kan använda detta API för att utföra CRUD-operationer på hinkar och objekt, samt för att ändra behörigheter och konfigurationer på båda.

Den primära distributionsmetoden för AWS CLI på Linux, Windows och macOS är pip, en pakethanterare för Python. Instruktioner finns här.

aws s3 cp severalnines.sql s3://severalnine-sbucket/MongoDB_backups
Som standard ger S3 elva 9s objekt hållbarhet. Det betyder att om du lagrar 1 000 000 000 (1 miljard) objekt i den, kan du förvänta dig att förlora 1 objekt vart tionde år i genomsnitt. Sättet som S3 uppnår ett imponerande antal 9:or är genom att replikera objektet automatiskt i flera tillgänglighetszoner, vilket vi kommer att prata om i ett annat inlägg. Amazon har regionala datacenter över hela världen.

Microsoft Azure Storage

Microsofts offentliga molnplattform, Azure, har lagringsalternativ med sitt kontrolllinjegränssnitt. Information finns här. Azure CLI med öppen källkod och flera plattformar tillhandahåller en uppsättning kommandon för att arbeta med Azure-plattformen. Det ger mycket av den funktionalitet som finns i Azure-portalen, inklusive rik dataåtkomst.

Installationen av Azure CLI är ganska enkel, du kan hitta instruktioner här. Nedan kan du se hur du överför din säkerhetskopia till Microsofts lagringsutrymme.

az storage blob upload --container-name severalnines --file severalnines.gz.tar --name severalnines_backup

Hybridlagring för MongoDB-säkerhetskopior

Med den växande offentliga och privata molnlagringsindustrin har vi en ny kategori som kallas hybridlagring. Det typiska tillvägagångssättet är att lagra data på lokala hårddiskar under en kortare period medan lagring av molnsäkerhetskopiering skulle hållas under en längre tid. Många gånger kommer kravet på längre säkerhetskopiering från juridiska skyldigheter för olika branscher (som telekom som måste lagra anslutningsmetadata). Denna teknik gör att filerna kan lagras lokalt, med ändringar som automatiskt synkroniseras till fjärrkontrollen i molnet. Ett sådant tillvägagångssätt kommer från behovet av att ha nya säkerhetskopior lagrade lokalt för snabb återställning (lägre RTO), såväl som affärskontinuitetsmål.

Den viktiga aspekten av effektiv resursanvändning är att ha separata säkerhetskopieringar. Data som lagras lokalt på redundanta hårddiskar skulle sparas under en kortare period medan molnsäkerhetslagring skulle hållas under en längre tid. Många gånger kommer kravet på längre säkerhetskopiering från juridiska skyldigheter för olika branscher (som telekom som måste lagra anslutningsmetadata).

Molnleverantörer som Google Cloud Services, Microsoft Azure och Amazon S3 erbjuder var och en praktiskt taget obegränsad lagring, vilket minskar behovet av lokalt utrymme. Det låter dig behålla dina säkerhetskopior längre, så länge du vill och inte ha problem med lokalt diskutrymme.

ClusterControl Backup Management - Hybrid Storage

När du schemalägger säkerhetskopiering med ClusterControl kan var och en av säkerhetskopieringsmetoderna konfigureras med en uppsättning alternativ för hur du vill att säkerhetskopieringen ska köras. Det viktigaste för hybridmolnlagring skulle vara:

  • Nätverksbegränsning
  • Kryptering med den inbyggda nyckelhanteringen
  • Kompression
  • Lagringsperioden för de lokala säkerhetskopiorna
  • Lagringsperioden för molnsäkerhetskopiorna

ClusterControl avancerade säkerhetskopieringsfunktioner för moln, parallell komprimering, nätverksbandbreddsgräns, kryptering , etc. Ditt företag kan dra fördel av molnets skalbarhet och betalbara priser för växande lagringsbehov. Du kan utforma en säkerhetskopieringsstrategi för att tillhandahålla både lokala kopior i datacentret för omedelbar återställning och en sömlös gateway till molnlagringstjänster från AWS, Google och Azure.

Avancerad TLS och AES 256 -bitars kryptering och komprimeringsfunktioner stöder säkra säkerhetskopieringar som tar upp betydligt mindre utrymme i molnet.


  1. mongo:avkastningen är inte lika med count()

  2. docker-compose:redis anslutning nekad mellan containrar

  3. Hur ansluter du till ett replikset från ett MongoDB-skal?

  4. MongoDB:locale::facet::_S_create_c_locale namn inte giltigt