Den nuvarande tekniska utvecklingen av alla aspekter av livet har gjort data mer värdefulla än guld och silver. Om du kan förvärva, växa och skydda data är du ett steg bort från att vara en datagud. Ändå är stora företag som kontrollerar livsaspekter som e-handel, bränsle, transport och matlandskap beroende av dataskydd för att skydda sig från en oundviklig kollaps.
Just nu är att förlora data som att förlora din livförsäkring. Så databashanteringssystemet du använder bör ha en säkerhetskopieringsorientering. Om du är en MySQL-administratör eller en användare som hanterar växande data, bör du överväga att implementera en mer än frekvent säkerhetskopieringsautomatiseringsplan. Anledning? Du kan hamna i ett offer för ett datahack eller till och med ändra din data av misstag.
Sådana omständigheter kan leda till oförlåtande dataintrång, särskilt när du inte har en säkerhetskopieringsplan för databasen. Om du är en investerad MySQL-användare eller administratör, är den här artikeln här för att fixa dina säkerhetskopieringsproblem. Vi kommer att uppfylla två mål. Först kommer du att förstå implementeringen av exporterande databaser genom "mysqldump". Sedan, slutligen, kommer vi att beröra hur användningen av "crontab" kan göra hela processen enklare genom automatisering.
Förbered en katalog för säkerhetskopiering av data
Eftersom Linux inte ger en användarrekommendation för en MySQL-destination för säkerhetskopiering av data, är det upp till dig att välja en lämplig plats för säkerhetskopiering. Till exempel, i den här självstudieguiden kommer vi att arbeta under en säkerhetskopieringskatalog i "/var/www_my_backups/". Vi överväger endast detta tillvägagångssätt för att förstå MySQL-mekanismerna för säkerhetskopiering av data. Helst rekommenderas det att säkerhetskopiering av alla viktiga data sker på en offside-server.
Du kan skapa din föredragna säkerhetskopieringskatalog på din lokala dator genom ett terminalkommando som liknar följande:
$ sudo mkdir /var/www_my_backups/
Se till att den Linux-styrda säkerhetskopieringsmaskinen du använder har privilegierat dig med root-åtkomst eller sudo-privilegier. Om du inte har ägaråtkomst till den skapade säkerhetskopieringskatalogen kommer du att möta behörighetsfel när du kör mysqldump-tester. Följande kommando bör lista den för närvarande aktiva systemanvändaren och detaljer om du har äganderättigheter på den skapade säkerhetskopieringsmappen.
$ sudo chown $(whoami):$(whoami) /var/www_my_backups/
Mysqldump-klientverktyget
Detta MySQL-verktyg gör logiska säkerhetskopieringar. Det resulterar i flera SQL-satsuppsättningar, som återskapar de ursprungliga databastabelldata och objektdefinitioner när de körs. Dessutom säkerhetskopieras en eller flera MySQL-databasdumpar eller överförs till en sekundär SQL-databasserver.
Ett standard mysqldump-kommando representeras av följande kommandosyntax.
$ mysqldump -u [mysql_användarnamn] -p[mysql_lösenord] [mysql_databasnamn]> /sökväg/till/[mysql_dump_filnamn].sql
- -u [mysql_username]: representerar en privilegierad användare av MySQL-databasen. Den här användaren bör kunna utföra databasdumpningsoperationer.
- -p[mysql_password]: representerar användarlösenordet för MySQL-databasen. Lägg inte till ett mellanslag mellan "-p" och "[mysql_lösenord]".
- [mysql_dump_file_name]: representerar namnet på din MySQL-databas.
- >: pekar på destinationen för utdatadumpen
- /sökväg/till/[mysql_dump_file_name].sql: pekar på sökvägen för den associerade dumpfilen. Du kan ge den här dumpfilen [mysql_dump_file_name] ett anpassat namn om du vill.
Innan vi fortsätter med den här handledningsguiden finns det något värt att nämna om "-p[mysql_password]". Även om den här artikelguiden kommer att fokusera på att associera dess användning med flera MySQL-dumpexempel, bör du undvika att använda den direkt när du hanterar dina riktiga MySQL-backupdumpar, särskilt i ett delat nätverk.
En löpande dump kan kapas med ett tvådimensionellt kommando som "ps axe", som avslöjar det associerade användarnamnet och lösenordet för databasen. Men att använda platsen "~/.my.cnf" för att lagra ditt MySQL-databaslösenord gör användningen av "-p[mysql_lösenord]" i det angivna dumpkommandot onödigt. Om detta dump-kommando körs genom ett cron-jobb, bör kommandoalternativet “–defaults-extra-file=/path/to/.my.cnf” peka mysqldump-kommandot till platsen för databaslösenordet.
Några exempel på säkerhetskopiering av MySQL-databas
Låt oss överväga flera användarscenarier där vi kan använda kommandot mysqldump för att säkerhetskopiera MySQL-databasdata.
Säkerhetskopiera alla databaser
Genom att använda kommandoalternativet "–all-databases" i ditt mysqldump-kommando tar du hand om alla MySQL-databasdumpar på ditt Linux-system. Till exempel, följande kommando visar hur du dumpar alla dina MySQL-databaser till den redan befintliga "/var/www_my_backups/"-filen. Användaren av detta Linux-system bör vara root eller ha sudo-privilegier.
I vårt fall, och för din förståelse, döpte vi vår dumpfil till "all-databases.sql", men du kan använda vilket namn som helst. Eftersom vi har att göra med alla databaser är det nödvändigt att vara ett root MySQL-konto.
$ mysqldump -u root -p[mysql_lösenord] --all-databases> /var/www_my_backups/all-databases.sql
Säkerhetskopiera en databas
Om bara en MySQL-databas är viktig för dig, måste du ersätta kommandoalternativet "[mysql_database]" för att skapa säkerhetskopian med kommandot mysqldump med det faktiska namnet. Dumpfilens namn kan ta namnet på denna databas "[mysql_database].sql" så att det blir lätt att spåra och återställa den senare. Du kan också välja ett annat anpassat dumpfilnamn om du vill.
Detta exempelkommando implementeras med hjälp av root-användaren, men alla andra användare med tillgång till den riktade databasen är ett genomförbart alternativ.
$ mysqldump -u root -p[mysql_lösenord] [mysql_database_name]> /var/www_my_backups/[mysql_database_name].sql
Säkerhetskopiera flera databaser
Kanske har du specifika MySQL-databaser som du vill säkerhetskopiera. I det här fallet kommer kommandoalternativet "[mysql_database_name]" att visas mer än en gång, och varje fall är associerat med namnet på databasen du vill säkerhetskopiera. Kom ihåg att placera dessa databasers namn på mysqldump-kommandot. Dumpfilen "[mysql_database_name].sql" bör också associeras med ett unikt namn som du kommer ihåg.
$ mysqldump -u root -p[mysql_lösenord] [mysql_database_1_name] [mysql_database_2_name]> /var/www_my_backups/[mysql_databases_1_2_names].sql
Säkerhetskopiera en enskild tabell
När din säkerhetskopieringsrutin endast är efter en specifik databastabell, bör skapande av dess säkerhetskopia ha både databasnamnet och databastabellnamnet som kommandoalternativ för mysqldump-kommandot. Du kan ge din dumpfil samma namn som den riktade databastabellen, t.ex. [mysql_database_table_name].sql.
$ mysqldump -u root -p[mysql_lösenord] [mysql_database_name] [mysql_database_table_name]> /var/www_my_backups/[mysql_databases_table_name].sql
Säkerhetskopiera flera tabeller
När du vill säkerhetskopiera många specifika MySQL-databastabeller, bör ett omnämnande av alla dina valda databastabellnamn komma efter databasnamnet som är värd för dessa tabeller. Den riktade dumpfilen kan ha ett namn som [mysql_database_tables_1_2_names].sql
$ mysqldump -u root -p[mysql_lösenord] [mysql_database_name] [mysql_database_table_1_name] [mysql_database_table_2_name]> /var/www_my_backups/[mysql_databases_tables_1_2_names]>s.Säkerhetskopiera en eller flera fjärrdatabas(er)
Denna exempelimplementering är också enkel. MySQL-databasdumpkommandot måste inkludera kommandoalternativet "-h" följt av fjärrmaskinens värdnamn eller associerade IP-adress. Alla andra vanliga kommandosyntaxer för säkerhetskopiering av databas bör sedan följa.
$ mysqldump -h [remote_computer_ip_or_hostname] -u root -p[mysql_password] [mysql_database_name]> /var/www_my_backups/[remote_mysql_database_name].sqlDu kan justera detta mysqldump-kommando för att hantera de andra fall av databassäkerhetskopiering som redan diskuterats, t.ex. MySQL-säkerhetskopior med flera databaser eller tabeller.
Säkerhetskopiera en databas associerad med komprimering
Om du vill associera dina säkerhetskopior av data med komprimering, visas "| gzip -c>” mysqldump kommandoalternativ kan användas för att pipe en gzip-utdata.
$ mysqldump -u root -p[mysql_lösenord] [mysql_database_name] | gzip -c> /var/www_my_backups/[mysql_database_name].sql.gzOm din MySQL-databas är enorm och du vill hålla reda på komprimeringsförloppet, överväg alltid att implementera det utförliga alternativet som visas i följande exempel.
$ mysqldump -u root -p[mysql_lösenord] [mysql_database_name] | gzip -c --verbose> /var/www_my_backups/[mysql_database_name].sql.gzÅterställer MySQL-databas
När du är klar med säkerhetskopieringen av din MySQL-databas, vad händer sedan? Hur kommer du åt de uppgifter som du så noggrant säkrat? Att återställa dina data kräver att du följer följande MySQL-återställningssyntax.
$ mysql -u [mysql_användarnamn] -p[mysql_lösenord] [mysql_databasnamn]Som du kanske inte har noterat är den enda skillnaden mellan detta databasåterställningskommando och databasbackupkommandot att vi använder alternativet "mysql" istället för alternativet "mysqldump" och alternativet "<" istället för alternativet ">".
Automatisk MySQL-säkerhetskopior
Operativsystemet Linux är utrustat med flera användbara tjänster som är ovärderliga för en databasadministratör som den under MySQL RDBMS. En av dessa tjänster är cron-tjänsten. Det är effektivt för att schemalägga automatiserade kommandon. Dessa kommandon, när de väl har skapats, allokeras till crontab-tabellen. Du kan komma åt crontab genom följande kommando.
$ sudo crontab -eOm du tillfrågas kanske det här kommandot vill associera dess körning till en textredigerare för att välja nanotextredigeraren.
En fil med ett namn som "/tmp/crontab.LVY6A9/crontab" öppnas. Längst ner i den här crontab-filen anger du ett genomförbart cron-schema tillsammans med ett tillämpligt MySQL-dumpkommando. Exemplet som illustreras nedan implementerar användningen av gzip-komprimering för dagliga databassäkerhetskopieringar. Ibland kan du ha stora .sql-filer planerade för säkerhetskopiering. Att använda gzip reducerar sådana filer till rimliga storlekar innan säkerhetskopiering. Det hjälper till med säkerhetskopiering av minneshantering.
00 03 * * * mysqldump -u root -p[mysql_lösenord] [mysql_databasnamn] | gzip -c> /var/www_my_backups/[mysql_database_name].sql.gzKommandoalternativet "00 03 ***" kan tolkas på följande sätt. Var 24:e timme efter 03:00 körs mysqldump-kommandot efter det för att säkerhetskopiera en databas. Databassäkerhetskopieringsfilen som för närvarande fanns innan denna säkerhetskopieringsprocess påbörjades skrivs över. I ditt fall behöver du inte vänta efter 24 timmar för att se din databassäkerhetskopieringsautomatisering i aktion via crontab.
Du kan redigera alternativet "00 03 ***" i crontab-filen till något i stil med "02 00 ***", och på bara två minuter bör säkerhetskopieringsprocessen självinitieras. Alternativt, om din tid är 22:30, kommer redigering av filen med "34 22 ***" att initiera säkerhetskopieringsprocessen för databasen vid 22:34. Kom ihåg att spara (Ctrl+X) denna crontab-fil innan du stänger den för att detta kommando ska bli körbart.
Efter att minuterna du ställt in har gått, borde cron-jobbet ha utförts. Lista sedan den skapade säkerhetskopieringsmappen på din terminal, och den skapade .sql.gz-säkerhetskopieringsfilen ska finnas.
$ ls -l /var/www_my_backups/Resultatet bör likna följande:
-rw-r--r-- 1 rotrot 36M 29 jul 22:24 [mysql_database_name].sql.gzOm du har problem med att upptäcka .sql.gz MySQL backup-filen, korrekturläs din crontab-tid eller hela kommandot. Det kan vara ett syntaxfel eller något kan saknas. Alternativt kan systemets cron-logg peka på var det finns ett problem.
$ sudo grep CRON /var/log/syslogKom ihåg att återställa crontab-posten till ditt föredragna databasschema när du har bekräftat att allt fungerar korrekt.
Använda my.cnf för att lagra MySQL-databaslösenord
Vi har redan nämnt nackdelarna med alternativet "-p[mysql_password]" på ett mysqldump-kommando, särskilt under ett delat nätverk. Vi måste diskutera hur man implementerar lösenordslagring i filen "~/.my.cnf". Användare som använder cron för att automatisera sina säkerhetskopieringar av databaser måste förstå implementeringen av kommandoalternativet “–defaults-extra-file=/path/to/.my.cnf”.
Redigera my.cnf-fil
Hemkatalogen för ditt Linux-system innehåller denna dolda fil. Den direkta systemsökvägen till den är "/home/ditt_användarnamn/.my.cnf". Använd nanotextredigeraren för att öppna den här filen. Alternativet "~" pekar på hemkatalogen.
$ sudo nano ~/.my.cnfRedigera denna öppna fil enligt följande syntax för att framgångsrikt lagra ditt MySQL-databaslösenord. Delen "DIN_DB_PASS" är den enda posten du behöver ändra med ditt faktiska databaslösenord. Ange dessa informationsdetaljer längst ner i filen och spara dem.
[mysqldump]
lösenord=DITT_DB_PASSAnvänd Ctrl+X för att spara den här filen. Denna "my.cnf"-fil behöver också vissa behörighetsinställningar. Implementera följande kommando:
$ sudo chmod 600 ~/.my.cnfDet är nu dags att se återskapandet av vårt nya mysqldump-kommando med kommandoalternativet "-p[mysql_password]" eliminerat.
$ mysqldump -u root [mysql_database_name] | gzip -c> /var/www_my_backups/[mysql_database_name].sql.gzSom du kan se har vi inte lagt till något. Det verkar bara som att det enda vi tog bort är kommandoalternativet "-p[mysql_password]".
Crontab och –defaults-extrs-file
För användare som föredrar att automatisera säkerhetskopiering av databas, måste du hämta databaslösenordet i filen "~/.my.cnf" genom kommandoalternativet "–defaults-extra-file". Detta tillvägagångssätt gör det enkelt för mysqldump-kommandot när det behöver referera till databasens användares och lösenordets äkthet. Du måste vara specifik om sökvägen till my.cnf-filen och inte bara använda "~"-symbolen. Tänk på följande implementering i crontab-filen:
30 22 * * * mysqldump --defaults-extra-file=/home/system_username/.my.cnf -u root [mysql_database_name] | gzip -c> /var/www_my_backups/[mysql_database_name].sql.gzI det här exemplet körs crontab varje dag klockan 22:30 för att skapa en säkerhetskopierad gzip-komprimering av MySQL-databasen.
Sista anmärkning
Den här artikeln tittade på lokala säkerhetskopieringsmekanismer för databasen om säkerhetskopieringskatalogen "/var/www_my_backups". Eftersom du nu förstår hur säkerhetskopieringsprocessen går till bör du skala högre och börja tänka på säkerhetskopiering utanför platsen. Ett mer praktiskt tillvägagångssätt är dock genom konfiguration av SFTP-åtkomst som pekar på denna "/var/www_my_backups" backupkatalog.
Med en sådan konfiguration på plats är det möjligt att skapa ett SFTP-cron-jobb via en fjärrserver för att hämta en kopia av dessa lokalt lagrade databasfiler för försäkringslagring nattetid och dagligen.
När vi avslutar den här fantastiska artikelguiden är du nu en stolt mästare på scenarier för säkerhetskopiering av MySQL-databas, återställning av databassäkerhetskopiering och automatisering av databassäkerhetskopiering. Du bör nu hoppa av tro och vara säker på att använda cron-jobb för att schemalägga och hantera din säkerhetskopiering av MySQL-databas. Automatiseringsscheman behöver inte vara dagliga eftersom de också kan vara veckovis och månadsvis.