డేటాబేస్ బ్యాకప్‌కి గైడ్

- ఓహ్, ఉల్క దెబ్బను ఏ ఆశ్రయం తట్టుకోదు. కానీ మీరు, అందరిలాగే, రిజర్వ్ కలిగి ఉంటారు, కాబట్టి మీరు చింతించాల్సిన అవసరం లేదు.

స్టానిస్లావ్ లెమ్, “స్టార్ డైరీస్ ఆఫ్ ఇజోన్ ది క్వైట్”

బ్యాకప్ అనేది డేటా కాపీని దాని ప్రాథమిక నిల్వ స్థానం వెలుపల ఎక్కడైనా సేవ్ చేయడాన్ని సూచిస్తుంది.

బ్యాకప్ యొక్క ముఖ్య ఉద్దేశ్యం డేటా పోయిన తర్వాత దానిని పునరుద్ధరించడం. ఈ విషయంలో, మీరు డేటాబేస్ ప్రతిరూపాన్ని కలిగి ఉంటే, మీరు ఎల్లప్పుడూ దాని నుండి డేటాను పునరుద్ధరించవచ్చు మరియు బ్యాకప్ అవసరం లేదని మీరు తరచుగా వింటారు. వాస్తవానికి, ప్రతిరూపాన్ని ఉపయోగించి పరిష్కరించలేని కనీసం మూడు సమస్యలను పరిష్కరించడానికి బ్యాకప్ మిమ్మల్ని అనుమతిస్తుంది మరియు బ్యాకప్ కాపీ లేకుండా ప్రతిరూపం ప్రారంభించబడదు.

మొదట, బ్యాకప్ లాజికల్ లోపం తర్వాత డేటాను పునరుద్ధరించడానికి మిమ్మల్ని అనుమతిస్తుంది. ఉదాహరణకు, ఒక అకౌంటెంట్ లావాదేవీల సమూహాన్ని తొలగించారు లేదా డేటాబేస్ అడ్మినిస్ట్రేటర్ టేబుల్ స్థలాన్ని నాశనం చేశారు. డేటాబేస్ దృక్కోణం నుండి రెండు కార్యకలాపాలు పూర్తిగా చట్టబద్ధమైనవి మరియు ప్రతిరూపణ ప్రక్రియ వాటిని ప్రతిరూప డేటాబేస్‌లో పునరుత్పత్తి చేస్తుంది.

రెండవది, ఆధునిక DBMSలు చాలా నమ్మదగిన సాఫ్ట్‌వేర్ సిస్టమ్‌లు, కానీ అప్పుడప్పుడు అంతర్గత డేటాబేస్ నిర్మాణాలకు నష్టం జరుగుతుంది, ఆ తర్వాత డేటాకు ప్రాప్యత పోతుంది. ప్రత్యేకించి అప్రియమైనది ఏమిటంటే, అటువంటి ఉల్లంఘన సాధారణంగా అధిక లోడ్లో లేదా ఒక రకమైన నవీకరణను ఇన్స్టాల్ చేస్తున్నప్పుడు సంభవిస్తుంది. కానీ అధిక లోడ్ మరియు సాధారణ నవీకరణలు రెండూ డేటాబేస్ పరీక్ష డేటాబేస్ కాదని సూచిస్తున్నాయి మరియు దానిలో నిల్వ చేయబడిన డేటా విలువైనది.

చివరగా, మూడవ పని, దీని పరిష్కారానికి బ్యాకప్ కాపీ అవసరం, డేటాబేస్ క్లోనింగ్, ఉదాహరణకు, పరీక్ష ప్రయోజనాల కోసం.

డేటాబేస్ బ్యాకప్ అనేది రెండు సూత్రాలలో ఒకదాని ఆధారంగా ఒక మార్గం లేదా మరొకటి:

• కస్టమ్ ఫార్మాట్‌లో డేటా నమూనా మరియు తదుపరి పొదుపు;
• డేటాబేస్ ఫైల్స్ మరియు సేవ్ లాగ్‌ల స్నాప్‌షాట్.

ఈ సూత్రాలు మరియు వాటిని అమలు చేసే సాధనాలను నిశితంగా పరిశీలిద్దాం.

డేటాను అప్‌లోడ్ చేస్తోంది

ఏదైనా DBMSతో చేర్చబడిన యుటిలిటీల సెట్ తప్పనిసరిగా డేటాను అప్‌లోడ్ చేయడానికి మరియు లోడ్ చేయడానికి సాధనాలను కలిగి ఉండాలి. డేటా టెక్స్ట్ ఫార్మాట్‌లో లేదా నిర్దిష్ట DBMSకి ప్రత్యేకంగా బైనరీ ఫార్మాట్‌లో నిల్వ చేయబడుతుంది. దిగువ పట్టిక అటువంటి సాధనాల జాబితాను అందిస్తుంది:

బైనరీ ఫార్మాట్
టెక్స్ట్ ఫార్మాట్

ఒరాకిల్
డేటా పంప్ ఎగుమతి/డేటా పంప్ దిగుమతి
ఎగుమతి దిగుమతి
SQL*ప్లస్/SQL*లోడర్

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL సర్వర్
BCP
BCP

DB2
అన్‌లోడ్/లోడ్ చేయండి
అన్‌లోడ్/లోడ్ చేయండి

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

కాసాండ్రా
nodetool స్నాప్‌షాట్/sstableloader
cqlsh

టెక్స్ట్ ఫార్మాట్ గురించిన మంచి విషయం ఏమిటంటే ఇది బాహ్య ప్రోగ్రామ్‌ల ద్వారా సవరించబడుతుంది లేదా సృష్టించబడుతుంది మరియు బైనరీ ఫార్మాట్ మంచిది, ఎందుకంటే ఫార్మాట్ మార్పిడిలో వనరులను సేవ్ చేయడం ద్వారా డేటాను వేగంగా అప్‌లోడ్ చేయడానికి మరియు డౌన్‌లోడ్ చేయడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది.

డేటాను డౌన్‌లోడ్ చేసే ఆలోచన యొక్క సరళత మరియు స్పష్టత ఉన్నప్పటికీ, లోడ్ చేయబడిన పారిశ్రామిక డేటాబేస్‌లను బ్యాకప్ చేయడానికి ఈ పద్ధతి చాలా అరుదుగా ఉపయోగించబడుతుంది. పూర్తి బ్యాకప్‌కు ఆఫ్‌లోడింగ్ ఎందుకు సరిపోదు అనే కారణాలు ఇక్కడ ఉన్నాయి:

• అన్‌లోడ్ ప్రక్రియ మూల వ్యవస్థపై గణనీయమైన లోడ్‌ను సృష్టిస్తుంది;
• అన్‌లోడ్ చేయడానికి చాలా సమయం పడుతుంది - అన్‌లోడ్ పూర్తయ్యే సమయానికి అది ఇకపై సంబంధితంగా ఉండదు;
• అధిక లోడ్‌లో ఉన్న మొత్తం డేటాబేస్‌ని సమన్వయంతో అన్‌లోడ్ చేయడం దాదాపు అసాధ్యం, ఎందుకంటే అన్‌లోడింగ్ ప్రారంభమయ్యే సమయంలో DBMS దాని స్థితి యొక్క స్నాప్‌షాట్‌ను నిల్వ చేయవలసి వస్తుంది. అప్‌లోడ్ చేయడం ప్రారంభించినప్పటి నుండి మరిన్ని లావాదేవీలు పూర్తయ్యాయి, స్నాప్‌షాట్ పరిమాణం పెద్దది (PostgreSQLలో డేటా యొక్క అసంబద్ధమైన కాపీలు, Oracleలో ఖాళీని రద్దు చేయడం, Microsoft SQL సర్వర్‌లో tempdb మొదలైనవి);
• అన్‌లోడ్ చేయడం డేటా యొక్క తార్కిక నిర్మాణాన్ని సంరక్షిస్తుంది, కానీ దాని భౌతిక నిర్మాణాన్ని సంరక్షించదు - పట్టికలు, సూచికలు మొదలైన వాటి యొక్క భౌతిక నిల్వ యొక్క పారామితులు.

అయితే, అప్‌లోడ్ చేయడం దాని ప్రయోజనాలను కూడా కలిగి ఉంది:

• అధిక ఎంపిక: మీరు వ్యక్తిగత పట్టికలు, వ్యక్తిగత ఫీల్డ్‌లు మరియు వ్యక్తిగత వరుసలను కూడా డౌన్‌లోడ్ చేసుకోవచ్చు;
• డౌన్‌లోడ్ చేయబడిన డేటా మరొక వెర్షన్ యొక్క డేటాబేస్‌లోకి లోడ్ చేయబడుతుంది మరియు డౌన్‌లోడ్ టెక్స్ట్ ఫార్మాట్‌లో చేయబడితే, మరొక డేటాబేస్‌లోకి లోడ్ చేయబడుతుంది.

అందువల్ల, అప్‌లోడ్ చేయడం ప్రధానంగా చిన్న పట్టికలను బ్యాకప్ చేయడం (ఉదాహరణకు, డైరెక్టరీలు) లేదా తదుపరి అప్లికేషన్ విడుదలతో డేటా సెట్‌లను పంపిణీ చేయడం వంటి పనుల కోసం ఉపయోగించబడుతుంది.

డేటాబేస్ బ్యాకప్ యొక్క అత్యంత సాధారణ పద్ధతి డేటాబేస్ ఫైళ్ళను కాపీ చేయడం.

డేటాబేస్ ఫైళ్ల కోల్డ్ స్టోరేజ్

డేటాబేస్‌ను ఆపివేసి, దానిలోని అన్ని ఫైల్‌లను కాపీ చేయడం స్పష్టమైన ఆలోచన. ఈ బ్యాకప్‌ను "కోల్డ్" బ్యాకప్ అంటారు. పద్ధతి చాలా నమ్మదగినది మరియు సరళమైనది, కానీ దీనికి రెండు స్పష్టమైన లోపాలు ఉన్నాయి:

• "చల్లని" బ్యాకప్ నుండి, మీరు షట్డౌన్ సమయంలో ఉన్న డేటాబేస్ స్థితిని మాత్రమే పునరుద్ధరించగలరు; డేటాబేస్ పునఃప్రారంభించిన తర్వాత చేసిన లావాదేవీలు "కోల్డ్" బ్యాకప్ కాపీలో చేర్చబడవు;
• డేటాబేస్ నిలిపివేయబడినప్పుడు ప్రతి డేటాబేస్కు సాంకేతిక విండో ఉండదు.

"చల్లని" బ్యాకప్ మీకు సరిపోతుంటే, మీరు దానిని గుర్తుంచుకోవాలి

• కోల్డ్ కాపీలో కొన్నిసార్లు లాగ్‌లు ఉండాలి. "కోల్డ్" కాపీకి వెళ్లవలసిన లాగ్‌లను నిర్ణయించే పద్ధతులు ప్రతి DBMSకి వ్యక్తిగతంగా ఉంటాయి. ఉదాహరణకు, ఒరాకిల్‌లో ఆన్‌లైన్ రీడో అని పిలవబడే వాటిని కాపీ చేయడం అవసరం, అంటే, డేటాబేస్ సరిగ్గా ఆపివేయబడినప్పటికీ, ప్రత్యేక డైరెక్టరీలో నిర్దిష్ట సంఖ్యలో లాగ్ ఫైల్‌లు. PostgreSQLలో, మీరు చివరి చెక్‌పాయింట్‌ను కలిగి ఉన్న లాగ్‌తో ప్రారంభించి అన్ని లాగ్‌లను తప్పనిసరిగా సేవ్ చేయాలి, దాని గురించిన సమాచారం నియంత్రణ ఫైల్‌లో ఉంటుంది.
• డేటాబేస్ డైరెక్టరీలో తాత్కాలిక టేబుల్‌స్పేస్ ఫైల్‌లు ఉండవచ్చు, అవి బ్యాకప్‌లో చేర్చాల్సిన అవసరం లేదు. మార్గం ద్వారా, ఈ వ్యాఖ్య హాట్ బ్యాకప్‌లకు కూడా వర్తిస్తుంది.

హాట్ ఫైల్ సేవింగ్

చాలా ఆధునిక డేటాబేస్ బ్యాకప్‌లు డేటాబేస్‌ను ఆపకుండా డేటాబేస్ ఫైల్‌లను కాపీ చేయడం ద్వారా నిర్వహించబడతాయి. ఇక్కడ అనేక సమస్యలు ఉన్నాయి:

• కాపీ చేయడం ప్రారంభించినప్పుడు, డేటాబేస్ యొక్క కంటెంట్‌లు ఫైల్‌ల కంటెంట్‌లతో ఏకీభవించకపోవచ్చు, ఎందుకంటే కొంత సమాచారం కాష్‌లో ఉంది మరియు ఇంకా డిస్క్‌కి వ్రాయబడలేదు.
• కాపీ చేసేటప్పుడు, డేటాబేస్ యొక్క కంటెంట్‌లు మారవచ్చు. మార్చగల డేటా నిర్మాణాలను ఉపయోగించినట్లయితే, ఫైల్‌ల కంటెంట్‌లు మారుతాయి మరియు మార్పులేని నిర్మాణాలను ఉపయోగించినప్పుడు, ఫైల్‌ల సెట్ మారుతుంది: కొత్త ఫైల్‌లు కనిపిస్తాయి మరియు పాతవి తొలగించబడతాయి.
• డేటాబేస్‌కు డేటాను వ్రాయడం మరియు డేటాబేస్ ఫైల్‌లను చదవడం ఏ విధంగానూ సమకాలీకరించబడనందున, బ్యాకప్ ప్రోగ్రామ్ తప్పు పేజీని చదవగలదు, దీనిలో సగం పేజీ యొక్క పాత సంస్కరణ నుండి మరియు మిగిలిన సగం కొత్తది నుండి ఉంటుంది.

బ్యాకప్ స్థిరంగా ఉండటానికి, ప్రతి DBMS బ్యాకప్ ప్రక్రియ ప్రారంభమైందని తెలియజేసే ఆదేశాన్ని కలిగి ఉంటుంది. వాక్యనిర్మాణం ప్రకారం, ఈ ఆదేశం భిన్నంగా కనిపిస్తుంది:

• ఒరాకిల్‌లో ఇది ఒక ప్రత్యేక కమాండ్ ఆల్టర్ డేటాబేస్/టేబుల్‌స్పేస్ ప్రారంభ బ్యాకప్;
• PostgreSQLలో – ఫంక్షన్ pg_start_backup();
• మైక్రోసాఫ్ట్ SQL సర్వర్ మరియు DB2లో, బ్యాకప్ డేటాబేస్ కమాండ్ అమలు సమయంలో బ్యాకప్ కోసం తయారీ పరోక్షంగా నిర్వహించబడుతుంది;
• MySQL Enterprise, Cassandra మరియు MongoDBలలో, తయారీ అనేది ఒక బాహ్య యుటిలిటీ ద్వారా పరోక్షంగా నిర్వహించబడుతుంది - mysqlbackup, OpsCenter మరియు Ops మేనేజర్, వరుసగా.

సింటాక్స్ తేడాలు ఉన్నప్పటికీ, బ్యాకప్ కోసం సిద్ధం చేసే ప్రక్రియ ఒకేలా కనిపిస్తుంది.

మార్చగల డిస్క్ నిర్మాణాలతో కూడిన DBMSలో, అంటే అన్ని సాంప్రదాయ డిస్క్ రిలేషనల్ సిస్టమ్‌లలో బ్యాకప్ కోసం తయారీ ఇలా కనిపిస్తుంది:

1. బ్యాకప్ ప్రారంభించిన క్షణం గుర్తుంచుకోబడుతుంది; బ్యాకప్ ఈ పాయింట్ నుండి ముందుకు డేటాబేస్ లాగ్‌లను కలిగి ఉండాలి.
2. చెక్‌పాయింట్ నిర్వహించబడుతుంది, అనగా, గుర్తుంచుకోబడిన క్షణానికి ముందు డేటా పేజీలలో సంభవించిన అన్ని మార్పులు డిస్క్‌కి ఫ్లష్ చేయబడతాయి. రికవరీ సమయంలో బ్యాకప్ ప్రారంభమయ్యే ముందు లాగ్‌లు అవసరం లేదని ఇది నిర్ధారిస్తుంది.
3. ఒక ప్రత్యేక లాగింగ్ మోడ్ ప్రారంభించబడింది: డిస్క్ నుండి లోడ్ అయిన తర్వాత మొదటిసారిగా డేటా పేజీ మారినట్లయితే, పేజీ మార్పులను లాగ్‌కు వ్రాయడానికి బదులుగా, డేటాబేస్ మొత్తం పేజీని అక్కడ వ్రాస్తుంది. తయారీ విధానాన్ని నిర్వహిస్తున్నప్పుడు, అన్ని పేజీలు డిస్క్‌కి ఫ్లష్ చేయబడతాయి, కాబట్టి మొదటిసారిగా మార్పు చేయబడినప్పుడు, మొత్తం బ్లాక్ ఎల్లప్పుడూ లాగ్‌కు వ్రాయబడుతుంది. కానీ బ్యాకప్ ప్రక్రియలో పేజీ మళ్లీ డిస్క్‌కి తొలగించబడినట్లయితే, దానికి తదుపరి మార్పు కూడా లాగ్‌లో పేజీ యొక్క పూర్తి కాపీని చూపుతుంది. డేటా ఫైల్‌ను కాపీ చేస్తున్నప్పుడు పేజీ తప్పు అని తేలితే, లాగ్‌ను వర్తింపజేయడం ద్వారా దాన్ని మళ్లీ సరిచేయవచ్చని ఇది నిర్ధారిస్తుంది.
4. డేటా ఫైల్ హెడర్‌లకు మార్పులు బ్లాక్ చేయబడ్డాయి, అంటే, లాగ్‌లలో మార్పులు ప్రతిబింబించని దానిలో కొంత భాగం. ఇది హెడర్ సరిగ్గా కాపీ చేయబడిందని నిర్ధారిస్తుంది మరియు డేటా ఫైల్‌కు లాగ్‌లు సరిగ్గా వర్తింపజేయబడతాయి.

పైన పేర్కొన్న అన్ని విధానాలు పూర్తయిన తర్వాత, మీరు ఆపరేటింగ్ సిస్టమ్ సాధనాలను ఉపయోగించి డేటా ఫైల్‌లను కాపీ చేయవచ్చు - cp, rsync మరియు ఇతరులు. బ్యాకప్ మోడ్‌ను ప్రారంభించడం వలన డేటాబేస్ పనితీరు తగ్గుతుంది: ముందుగా, లాగ్‌ల వాల్యూమ్ పెరుగుతుంది మరియు రెండవది, బ్యాకప్ మోడ్‌లో అకస్మాత్తుగా వైఫల్యం సంభవించినట్లయితే, డేటా ఫైల్‌ల హెడర్‌లు నవీకరించబడనందున రికవరీ ఎక్కువ సమయం పడుతుంది. బ్యాకప్ ఎంత వేగంగా పూర్తయితే, డేటాబేస్‌కు అంత మంచిది, కాబట్టి ఫైల్ సిస్టమ్ యొక్క స్నాప్‌షాట్ లేదా డిస్క్ శ్రేణిలో మిర్రర్ (BCV)ని విచ్ఛిన్నం చేయడం వంటి సాధనాలను ఉపయోగించడం సముచితం. కొన్ని DBMSలు (Oracle, PostgreSQL) కాపీయింగ్ పద్ధతిని స్వతంత్రంగా ఎంచుకునే అవకాశాన్ని నిర్వాహకులకు వదిలివేస్తాయి, మరికొన్ని (మైక్రోసాఫ్ట్ SQL సర్వర్) ఫైల్ సిస్టమ్ లేదా స్టోరేజ్ మెకానిజమ్‌లతో తమ స్వంత బ్యాకప్ యుటిలిటీలను ఏకీకృతం చేయడానికి ఇంటర్‌ఫేస్‌ను అందిస్తాయి.

బ్యాకప్ పూర్తయిన తర్వాత, మీరు డేటాబేస్‌ను దాని సాధారణ స్థితికి తిరిగి ఇవ్వాలి. Oracleలో ఇది ALTER DATABASE/TABLESPACE END BACKUP కమాండ్‌తో, PostgreSQLలో pg_stop_backup() ఫంక్షన్‌కు కాల్ చేయడం ద్వారా మరియు ఇతర డేటాబేస్‌లలో సంబంధిత కమాండ్‌లు లేదా బాహ్య సేవల అంతర్గత రొటీన్‌ల ద్వారా చేయబడుతుంది.

బ్యాకప్ ప్రాసెస్ టైమ్‌లైన్ ఎలా ఉంటుందో ఇక్కడ ఉంది:

• బ్యాకప్ కోసం సిద్ధం కావడానికి సమయం పడుతుంది, కొన్నిసార్లు గణనీయమైన సమయం పడుతుంది. మిర్రర్డ్ వాల్యూమ్‌లు లేదా స్నాప్‌షాట్-సామర్థ్యం గల ఫైల్ సిస్టమ్‌లను ఉపయోగించినప్పటికీ, బ్యాకప్ ప్రక్రియ తక్షణమే జరగదు.
• డేటా ఫైల్‌లతో పాటు, మీరు బ్యాకప్ కోసం ప్రిపరేషన్ ప్రారంభించిన క్షణం నుండి డేటాబేస్ దాని సాధారణ స్థితికి వచ్చే వరకు లాగ్‌లను సేవ్ చేయడం అవసరం.
• మీరు ఈ బ్యాకప్ నుండి పునరుద్ధరించవచ్చు ఆ సమయంలో బేస్ సాధారణ స్థితికి తిరిగి వస్తుంది. మునుపటి పాయింట్‌కి పునరుద్ధరించడం సాధ్యం కాదు.

మార్పులేని డేటా నిర్మాణాలను (మెమరీ స్నాప్‌షాట్‌లు, LSM ట్రీలు) ఉపయోగించే డేటాబేస్‌లతో, పరిస్థితి సరళంగా ఉంటుంది. బ్యాకప్ కోసం సిద్ధం చేయడం క్రింది దశలను కలిగి ఉంటుంది:

1. మెమరీ నుండి డేటా డిస్క్‌కి ఫ్లష్ చేయబడింది.
2. బ్యాకప్ కాపీలో చేర్చబడిన ఫైల్‌ల జాబితా రికార్డ్ చేయబడింది. బ్యాకప్ ప్రక్రియ పూర్తయ్యే వరకు, ఈ ఫైల్‌లు ఇకపై అవసరం లేకపోయినా డేటాబేస్ తొలగించడం నిషేధించబడింది.

బ్యాకప్ పూర్తయిందని సిగ్నల్ ఇచ్చిన తర్వాత, మార్పులేని నిర్మాణాలతో ఉన్న డేటాబేస్ మళ్లీ అనవసరమైన ఫైల్‌లను తొలగించగలదు.

పాయింట్ టు పాయింట్ రికవరీ

బ్యాకప్ మోడ్ నుండి రిటర్న్ కమాండ్ పూర్తయిన క్షణానికి డేటాబేస్ స్థితిని పునరుద్ధరించడానికి బ్యాకప్ కాపీ మిమ్మల్ని అనుమతిస్తుంది. అయితే, కోలుకోవాల్సిన ప్రమాదం ఎప్పుడైనా జరగవచ్చు. ఏకపక్ష క్షణంలో డేటాబేస్ స్థితిని పునరుద్ధరించే పనిని "పాయింట్-ఇన్-టైమ్ రికవరీ" అంటారు.

ఇది సాధ్యమని నిర్ధారించడానికి, మీరు బ్యాకప్ చివరి నుండి డేటాబేస్ లాగ్‌లను సేవ్ చేయాలి మరియు రికవరీ ప్రక్రియ సమయంలో, పునరుద్ధరించబడిన కాపీకి లాగ్‌లను వర్తింపజేయడం కొనసాగించండి. కాపీ చేయడం పూర్తయిన సమయంలో బ్యాకప్ కాపీ నుండి డేటాబేస్ పునరుద్ధరించబడిన తర్వాత, డేటాబేస్ స్థితి (ఫైళ్లు మరియు కాష్ చేసిన పేజీలు) సరైనదని హామీ ఇవ్వబడుతుంది, కాబట్టి ప్రత్యేక లాగింగ్ మోడ్ అవసరం లేదు. సరైన సమయంలో లాగ్‌లను వర్తింపజేయడం ద్వారా, మీరు ఏ సమయంలోనైనా డేటాబేస్ స్థితిని పొందవచ్చు.

బ్యాకప్ పునరుద్ధరించబడే వేగం డిస్క్ బ్యాండ్‌విడ్త్ ద్వారా మాత్రమే పరిమితం చేయబడింది, లాగ్‌లను వర్తించే వేగం సాధారణంగా ప్రాసెసర్ పనితీరు ద్వారా పరిమితం చేయబడుతుంది. ప్రధాన డేటాబేస్లో మార్పులు సమాంతరంగా జరిగితే, రికవరీ సమయంలో అన్ని మార్పులు వరుసగా నిర్వహించబడతాయి - క్రమంలో అవి లాగ్ నుండి చదవబడతాయి. అందువలన, పునరుద్ధరణ సమయం బ్యాకప్ యొక్క ముగింపు స్థానం నుండి రికవరీ పాయింట్ ఎంత దూరంలో ఉందో దానిపై ఆధారపడి ఉంటుంది. దీని కారణంగా, చాలా తరచుగా పూర్తి బ్యాకప్‌లను తయారు చేయడం అవసరం - చిన్న లావాదేవీల లోడ్‌తో కూడిన డేటాబేస్‌ల కోసం మరియు అత్యధికంగా లోడ్ చేయబడిన డేటాబేస్‌ల రోజువారీ కాపీల కోసం కనీసం వారానికి ఒకసారి.

పెరుగుతున్న బ్యాకప్

రికవరీని వేగవంతం చేయడానికి, నేను వీలైనంత తరచుగా బ్యాకప్‌లను నిర్వహించాలనుకుంటున్నాను, అయితే అదే సమయంలో అదనపు డిస్క్ స్థలాన్ని తీసుకోవద్దు మరియు బ్యాకప్ టాస్క్‌లతో డేటాబేస్‌ను లోడ్ చేయకూడదు.

సమస్యకు పరిష్కారం పెరుగుతున్న బ్యాకప్, అంటే మునుపటి బ్యాకప్ నుండి మారిన డేటా పేజీలను మాత్రమే కాపీ చేయడం.
మార్చగల డేటా నిర్మాణాలను ఉపయోగించే DBMSలకు మాత్రమే పెరుగుతున్న బ్యాకప్‌లు అర్ధవంతంగా ఉంటాయి.

ఇంక్రిమెంట్ పూర్తి బ్యాకప్ (సంచిత కాపీ) లేదా ఏదైనా మునుపటి కాపీ (డిఫరెన్షియల్ కాపీ) నుండి లెక్కించబడుతుంది.

దురదృష్టవశాత్తు, ఏకరీతి పదజాలం లేదు మరియు వేర్వేరు తయారీదారులు వేర్వేరు పదాలను ఉపయోగిస్తారు:

అవకలన
సంచిత

ఒరాకిల్
అవకలన
సంచిత

PostgreSQL
పెరుగుతున్న
-

Microsoft SQL సర్వర్
-
అవకలన

IBM DB2
డెల్టా
పెరుగుతున్న

ఇంక్రిమెంటల్ కాపీలు ఉంటే, ఒక పాయింట్‌కి పునరుద్ధరించే ప్రక్రియ క్రింది విధంగా ఉంటుంది:

• పునరుద్ధరణ పునరుద్ధరించబడటానికి ముందు చేసిన చివరి పూర్తి బ్యాకప్;
• పూర్తి కాపీ పైన ఇంక్రిమెంటల్ కాపీలు పునరుద్ధరించబడతాయి;
• లాగ్‌లు బ్యాకప్ ప్రారంభ స్థానం నుండి రికవరీ పాయింట్ వరకు చుట్టబడతాయి.

సంచిత కాపీని కలిగి ఉండటం రికవరీ ప్రక్రియను వేగవంతం చేస్తుంది. కాబట్టి, ఉదాహరణకు, డేటాబేస్ యొక్క స్థితిని T3 మరియు T4 మధ్య బిందువుకు పునరుద్ధరించడానికి, రెండు పెరుగుతున్న కాపీలను పునరుద్ధరించడం అవసరం, మరియు T4 తర్వాత ఒక పాయింట్‌కి పునరుద్ధరించడానికి, ఒకటి మాత్రమే.
సహజంగానే, ఒక సంచిత కాపీ పరిమాణం అనేక అవకలన కాపీల పరిమాణం కంటే చిన్నది, ఎందుకంటే కొన్ని పేజీలు చాలా సార్లు మారాయి మరియు ప్రతి పెరుగుతున్న కాపీ పేజీ యొక్క విభిన్న సంస్కరణను కలిగి ఉంటుంది.

పెరుగుతున్న కాపీని సృష్టించడానికి మూడు మార్గాలు ఉన్నాయి:

1. పూర్తి కాపీని సృష్టించడం మరియు మునుపటి పూర్తి కాపీతో వ్యత్యాసాన్ని లెక్కించడం;
2. లాగ్‌లను అన్వయించడం, మార్చబడిన పేజీల జాబితాను సృష్టించడం మరియు జాబితాలో చేర్చబడిన పేజీలను బ్యాకప్ చేయడం;
3. డేటాబేస్లో మార్చబడిన పేజీలను ప్రశ్నించడం.

మొదటి పద్ధతి డిస్క్ స్పేస్‌ను ఆదా చేస్తుంది, కానీ డేటాబేస్‌పై భారాన్ని తగ్గించదు. అంతేకాకుండా, మన వద్ద పూర్తి బ్యాకప్ ఉన్నప్పుడు, దానిని ఇంక్రిమెంటల్ బ్యాకప్‌గా మార్చడం అనవసరం, ఎందుకంటే మునుపటి పూర్తి బ్యాకప్ మరియు ఒక ఇంక్రిమెంటల్ బ్యాకప్‌ను పునరుద్ధరించడం కంటే పూర్తి బ్యాకప్‌ను పునరుద్ధరించడం వేగంగా ఉంటుంది. ఈ విధానంతో డిస్క్ స్పేస్‌ను ఆదా చేసే పనిని, అంతర్నిర్మిత డీడ్యూప్లికేషన్ మెకానిజమ్‌లతో కూడిన ప్రత్యేక భాగాలకు అప్పగించడం ఉత్తమం. ఇవి ప్రత్యేక స్టోరేజ్ సిస్టమ్‌లు (EMC డేటాడొమైన్, HPE స్టోరేజ్‌వర్క్స్ VLS, మొత్తం నెట్‌యాప్ శ్రేణి) లేదా సాఫ్ట్‌వేర్ ఉత్పత్తులు (ZFS, వెరిటాస్ నెట్‌బ్యాకప్ ప్యూర్‌ఫైల్) కావచ్చు. Windows Server డేటా డీడ్యూప్లికేషన్).

మార్చబడిన పేజీల జాబితాను నిర్ణయించే విధానంలో రెండవ మరియు మూడవ పద్ధతులు విభిన్నంగా ఉంటాయి. లాగ్‌లను అన్వయించడం అనేది మరింత వనరు-ఇంటెన్సివ్, దాన్ని అమలు చేయడానికి మీరు లాగ్ ఫైల్‌ల నిర్మాణాన్ని తెలుసుకోవాలి. ఏ పేజీలు మారాయి అని డేటాబేస్‌ని అడగడం సులభమయిన మార్గం, అయితే దీని కోసం DBMS కెర్నల్ బ్లాక్ చేంజ్ ట్రాకింగ్ ఫంక్షనాలిటీని కలిగి ఉండాలి.

ఒరాకిల్ రికవరీ మేనేజర్ (RMAN) సాఫ్ట్‌వేర్‌లో ఇంక్రిమెంటల్ బ్యాకప్ ఫంక్షనాలిటీ మొదట పరిచయం చేయబడింది, ఇది ఒరాకిల్ 8i విడుదలలో ప్రవేశపెట్టబడింది. ఒరాకిల్ వెంటనే మార్చబడిన బ్లాక్‌ల ట్రాకింగ్‌ను అమలు చేసింది, కాబట్టి లాగ్‌లను అన్వయించాల్సిన అవసరం లేదు.

PostgreSQL సవరించిన బ్లాక్‌లను ట్రాక్ చేయదు, కాబట్టి రష్యన్ కంపెనీ Postgres Professional చే అభివృద్ధి చేయబడిన pg_probackup యుటిలిటీ, లాగ్‌ను విశ్లేషించడం ద్వారా సవరించిన పేజీలను నిర్ణయిస్తుంది. అయితే, కంపెనీ పోస్ట్‌గ్రెస్‌ప్రో DBMSని కూడా సరఫరా చేస్తుంది, ఇందులో పేజీ మార్పులను ట్రాక్ చేసే ptrack పొడిగింపు ఉంటుంది. PostgresPro DBMSతో pg_probackupని ఉపయోగిస్తున్నప్పుడు, వినియోగ అభ్యర్థనలు డేటాబేస్ నుండి పేజీలను మార్చాయి - సరిగ్గా RMAN వలె.

మైక్రోసాఫ్ట్ SQL సర్వర్, ఒరాకిల్ వంటి, మార్చబడిన పేజీలను ట్రాక్ చేస్తుంది, అయితే BACKUP కమాండ్ మిమ్మల్ని పూర్తి మరియు సంచిత బ్యాకప్‌లను చేయడానికి మాత్రమే అనుమతిస్తుంది.

DB2 మార్చబడిన పేజీలను ట్రాక్ చేయగల సామర్థ్యాన్ని కలిగి ఉంది, కానీ అది డిఫాల్ట్‌గా నిలిపివేయబడుతుంది. ప్రారంభించిన తర్వాత, DB2 పూర్తి, అవకలన మరియు సంచిత బ్యాకప్‌లను అనుమతిస్తుంది.

ఈ విభాగంలో వివరించిన సాధనాలు (pg_probackup మినహా) మరియు ఫైల్ బ్యాకప్ సాధనాల మధ్య ముఖ్యమైన వ్యత్యాసం ఏమిటంటే అవి డిస్క్ నుండి డేటాను చదవడం కంటే డేటాబేస్ నుండి పేజీ చిత్రాలను అభ్యర్థించడం. ఈ విధానం యొక్క ప్రతికూలత బేస్ మీద ఒక చిన్న అదనపు లోడ్. ఏదేమైనప్పటికీ, ఈ లోపము పేజీని చదవడం ఎల్లప్పుడూ సరైనది అనే వాస్తవం ద్వారా భర్తీ చేయబడిన దాని కంటే ఎక్కువగా ఉంటుంది, కాబట్టి బ్యాకప్ సమయంలో ప్రత్యేక లాగింగ్ మోడ్‌ను ప్రారంభించాల్సిన అవసరం లేదు.

దయచేసి ఇంక్రిమెంటల్ కాపీలు ఉండటం వల్ల రికవరీ కోసం ఏకపక్ష సమయానికి లాగ్‌లు అందుబాటులో ఉండాల్సిన అవసరాన్ని తొలగించలేరని మళ్లీ గమనించండి. అందువల్ల, పారిశ్రామిక డేటాబేస్‌లలో, లాగ్‌లు నిరంతరం బాహ్య మీడియాకు తిరిగి వ్రాయబడతాయి మరియు బ్యాకప్‌లు, పూర్తి మరియు/లేదా ఇంక్రిమెంటల్, షెడ్యూల్‌లో సృష్టించబడతాయి.

ఈ రోజు ఇంక్రిమెంటల్ బ్యాకప్ ఆలోచన యొక్క ఉత్తమ అమలు జీరో డేటా లాస్ రికవరీ ఉపకరణం, ఇది ఒక హార్డ్‌వేర్ మరియు సాఫ్ట్‌వేర్ వ్యవస్థ (ఒరాకిల్ పరిభాషలో, ఒక ఇంజనీరింగ్ వ్యవస్థ) - దాని స్వంత డేటాబేస్‌ను బ్యాకప్ చేయడానికి ఒక ప్రత్యేకమైన ఒరాకిల్ పరిష్కారం. ఈ వ్యవస్థ ఒక క్లస్టర్. సర్వర్లు ZDLRA పెద్ద డిస్క్ సామర్థ్యాలను కలిగి ఉంది మరియు రికవరీ మేనేజర్ సాఫ్ట్‌వేర్ యొక్క సవరించిన సంస్కరణను అమలు చేస్తుంది. ఇది ఇతర Oracle హార్డ్‌వేర్ మరియు సాఫ్ట్‌వేర్ సిస్టమ్‌లతో (డేటాబేస్ అప్లయన్స్, ఎక్సాడేటా, SPARC సూపర్‌క్లస్టర్) అలాగే సాంప్రదాయ మౌలిక సదుపాయాలపై నడుస్తున్న Oracle డేటాబేస్‌లతో పని చేయగలదు. "రెగ్యులర్" RMAN వలె కాకుండా, ZDLRA "ఇంక్రిమెంటల్ ఫరెవర్" భావనను అమలు చేస్తుంది. సిస్టమ్ ఒకసారి పూర్తి డేటాబేస్ కాపీని సృష్టిస్తుంది మరియు తరువాత ఇంక్రిమెంటల్ కాపీలను మాత్రమే చేస్తుంది. అదనపు RMAN మాడ్యూల్స్ మీరు కాపీలను విలీనం చేయడానికి అనుమతిస్తాయి, ఇంక్రిమెంటల్ వాటి నుండి కొత్త పూర్తి కాపీలను సృష్టిస్తాయి.

రష్యన్ డెవలపర్‌ల క్రెడిట్‌కి, pg_probackup కూడా పెరుగుతున్న కాపీలను విలీనం చేయగలదని గమనించాలి.

అనేక సారూప్య ప్రశ్నలకు భిన్నంగా, “ఏ బ్యాకప్ పద్ధతి ఉత్తమం” అనే ప్రశ్నకు స్పష్టమైన సమాధానం ఉంది - ఉత్తమ ఎంపిక DBMS ఉపయోగించబడుతున్న యుటిలిటీ, ఇది పెరుగుతున్న బ్యాకప్‌ల సామర్థ్యాన్ని అందిస్తుంది.

డేటాబేస్ అడ్మినిస్ట్రేటర్ కోసం, బ్యాకప్ స్ట్రాటజీని ఎంచుకోవడం మరియు కార్పొరేట్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో డేటాబేస్ బ్యాకప్ సాధనాలను సమగ్రపరచడం వంటి సమస్యలు చాలా ముఖ్యమైనవి. కానీ ఈ ప్రశ్నలు ఈ వ్యాసం యొక్క పరిధికి మించినవి.

మూలం: www.habr.com