పెద్ద NextCloud నిల్వలను బ్యాకప్ చేయడానికి GitLab మీకు ఎలా సహాయపడుతుంది

హే హబ్ర్!

ఈ రోజు నేను వివిధ కాన్ఫిగరేషన్‌లలో Nextcloud నిల్వల నుండి పెద్ద డేటా యొక్క బ్యాకప్‌ను ఆటోమేట్ చేయడంలో మా అనుభవం గురించి మాట్లాడాలనుకుంటున్నాను. నేను మోల్నియా AKలో సర్వీస్ స్టేషన్‌గా పని చేస్తున్నాను, ఇక్కడ మేము IT సిస్టమ్‌ల కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ చేస్తాము; డేటా నిల్వ కోసం Nextcloud ఉపయోగించబడుతుంది. రిడెండెన్సీతో, పంపిణీ చేయబడిన నిర్మాణంతో సహా.

ఇన్‌స్టాలేషన్‌ల లక్షణాల నుండి ఉత్పన్నమయ్యే సమస్యలు చాలా డేటా ఉన్నాయి. Nextcloud, రిడెండెన్సీ, సబ్జెక్టివ్ కారణాలు మరియు మరిన్ని అందించిన సంస్కరణ అనేక నకిలీలను సృష్టిస్తుంది.

పూర్వచరిత్ర

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

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

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

ముందుగా, ఇన్‌పుట్ డేటాను చూద్దాం. మాకు అవసరము:

• ఒక నోడ్ లేదా అనేక పరంగా స్కేలబిలిటీ. పెద్ద ఇన్‌స్టాలేషన్‌ల కోసం మేము మినియోని నిల్వగా ఉపయోగిస్తాము.
• బ్యాకప్‌లను ప్రదర్శించడంలో సమస్యల గురించి తెలుసుకోండి.
• మీరు మీ క్లయింట్‌లతో మరియు/లేదా మాతో బ్యాకప్‌ని ఉంచుకోవాలి.
• సమస్యలను త్వరగా మరియు సులభంగా పరిష్కరించండి.
• క్లయింట్లు మరియు ఇన్‌స్టాలేషన్‌లు ఒకదానికొకటి చాలా భిన్నంగా ఉంటాయి - ఏకరూపతను సాధించలేము.
• రికవరీ వేగం రెండు దృశ్యాలలో తక్కువగా ఉండాలి: పూర్తి పునరుద్ధరణ (విపత్తు), పొరపాటున ఒక ఫోల్డర్ తొలగించబడింది.
• డూప్లికేషన్ ఫంక్షన్ అవసరం.

బ్యాకప్‌లను నిర్వహించడంలో సమస్యను పరిష్కరించడానికి, మేము GitLabని ఇన్‌స్టాల్ చేసాము. టాకిల్ ద్వారా మరిన్ని వివరాలు.

వాస్తవానికి, అటువంటి సమస్యను పరిష్కరించడంలో మేము మొదటి వ్యక్తి కాదు, కానీ మన ఆచరణాత్మక, కష్టపడి సంపాదించిన అనుభవం ఆసక్తికరంగా ఉంటుందని మరియు మేము దానిని పంచుకోవడానికి సిద్ధంగా ఉన్నామని మాకు అనిపిస్తుంది.

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

బ్యాకప్ సాధనాలు

మేము బ్యాకప్ సృష్టి సాధనాన్ని ఎంచుకోవడం ద్వారా పరిష్కార పద్ధతుల కోసం మా శోధనను ప్రారంభించాము.

సాధారణ tar + gzip బాగా పని చేయదు - డేటా నకిలీ చేయబడింది. ఇంక్రిమెంట్ తరచుగా చాలా తక్కువ వాస్తవ మార్పులను కలిగి ఉంటుంది మరియు ఒకే ఫైల్‌లోని చాలా డేటా పునరావృతమవుతుంది.
మరొక సమస్య ఉంది - పంపిణీ చేయబడిన డేటా నిల్వ యొక్క రిడెండెన్సీ. మేము మినియోని ఉపయోగిస్తాము మరియు దాని డేటా ప్రాథమికంగా అనవసరమైనది. లేదా మీరు మినియో ద్వారా బ్యాకప్ చేయవలసి ఉంటుంది - దానిని లోడ్ చేయండి మరియు ఫైల్ సిస్టమ్ మధ్య అన్ని స్పేసర్‌లను ఉపయోగించండి మరియు తక్కువ ముఖ్యమైనది కాదు, కొన్ని బకెట్లు మరియు మెటా-సమాచారం గురించి మరచిపోయే ప్రమాదం ఉంది. లేదా డూప్లికేషన్ ఉపయోగించండి.

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

బ్యాకప్‌లను నిర్వహించడం

బోర్గ్ మరియు రెస్టిక్ మంచివి, కానీ ఏ ఉత్పత్తిలోనూ కేంద్రీకృత నియంత్రణ యంత్రాంగం లేదు. నిర్వహణ మరియు నియంత్రణ ప్రయోజనం కోసం, మేము ఇప్పటికే అమలు చేసిన సాధనాన్ని ఎంచుకున్నాము, ఇది లేకుండా ఆటోమేషన్‌తో సహా మా పనిని ఊహించలేము - ఇది బాగా తెలిసిన CI/CD - GitLab.

ఆలోచన క్రింది విధంగా ఉంది: Nextcloud డేటాను నిల్వ చేసే ప్రతి నోడ్‌లో gitlab-రన్నర్ ఇన్‌స్టాల్ చేయబడుతుంది. బ్యాకప్ ప్రాసెస్‌ను పర్యవేక్షించే షెడ్యూల్‌లో రన్నర్ స్క్రిప్ట్‌ను అమలు చేస్తాడు మరియు అది బోర్గ్ లేదా రెస్టిక్‌ను ప్రారంభిస్తుంది.

మేము ఏమి పొందాము? అమలు నుండి అభిప్రాయం, మార్పులపై అనుకూలమైన నియంత్రణ, లోపం సంభవించినప్పుడు వివరాలు.

ఇక్కడ ఇక్కడ GitHub లో మేము వివిధ పనుల కోసం స్క్రిప్ట్ యొక్క ఉదాహరణలను పోస్ట్ చేసాము మరియు మేము దానిని Nextcloud మాత్రమే కాకుండా అనేక ఇతర సేవల బ్యాకప్‌కు జోడించడం ముగించాము. మీరు దీన్ని మాన్యువల్‌గా కాన్ఫిగర్ చేయకూడదనుకుంటే (మరియు మేము కోరుకోవడం లేదు) మరియు .gitlab-ci.yml అక్కడ షెడ్యూలర్ కూడా ఉంది

Gitlab APIలో CI/CD గడువును మార్చడానికి ఇంకా మార్గం లేదు, కానీ ఇది చిన్నది. ఇది పెంచాలి, చెప్పండి 1d.

GitLab, అదృష్టవశాత్తూ, నిబద్ధత ప్రకారం మాత్రమే కాకుండా, షెడ్యూల్ ప్రకారం మాత్రమే ప్రారంభించవచ్చు, ఇది మనకు అవసరమైనది.

ఇప్పుడు రేపర్ స్క్రిప్ట్ గురించి.

మేము ఈ స్క్రిప్ట్ కోసం క్రింది షరతులను సెట్ చేసాము:

• ఇది ఒకే కార్యాచరణతో కన్సోల్ నుండి రన్నర్ ద్వారా మరియు చేతితో ప్రారంభించబడాలి.
• లోపం హ్యాండ్లర్లు ఉండాలి:
• రిటర్న్ కోడ్.
• లాగ్‌లో స్ట్రింగ్ కోసం శోధించండి. ఉదాహరణకు, మాకు ఒక లోపం ప్రోగ్రామ్ ప్రాణాంతకంగా పరిగణించబడని సందేశం కావచ్చు.
• ప్రాసెసింగ్ గడువు ముగిసింది. ప్రధాన సమయం సహేతుకంగా ఉండాలి.
• మాకు చాలా వివరణాత్మక లాగ్ అవసరం. కానీ లోపం విషయంలో మాత్రమే.
• ప్రారంభించడానికి ముందు అనేక పరీక్షలు కూడా నిర్వహించబడతాయి.
• సపోర్ట్ ప్రాసెస్ సమయంలో మేము ఉపయోగకరంగా ఉన్న సౌలభ్యం కోసం చిన్న బోనస్‌లు:
• ప్రారంభం మరియు ముగింపు స్థానిక యంత్రం యొక్క సిస్లాగ్‌లో నమోదు చేయబడతాయి. ఇది సిస్టమ్ లోపాలను మరియు బ్యాకప్ ఆపరేషన్‌ను కనెక్ట్ చేయడానికి సహాయపడుతుంది.
• లోపం లాగ్‌లో కొంత భాగం, ఏదైనా ఉంటే, stdoutకి అవుట్‌పుట్ చేయబడుతుంది, మొత్తం లాగ్ ప్రత్యేక ఫైల్‌కి వ్రాయబడుతుంది. అది చిన్నవిషయమైతే వెంటనే CIని పరిశీలించి, లోపాన్ని మూల్యాంకనం చేయడం సౌకర్యంగా ఉంటుంది.
• డీబగ్గింగ్ మోడ్‌లు.

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

ఓపెన్ సోర్స్‌కు సంబంధించి ఏవైనా సూచనలు మరియు వ్యాఖ్యలను పరిగణనలోకి తీసుకోవడానికి మేము సంతోషిస్తాము - స్వాగతం.

ఎలా పని చేస్తుంది

బ్యాష్ ఎగ్జిక్యూటర్‌తో రన్నర్ బ్యాకప్ నోడ్‌లో ప్రారంభించబడింది. షెడ్యూలర్ ప్రకారం, జాబ్ CI/CD ప్రత్యేక టర్నిప్‌లో ప్రారంభించబడింది. రన్నర్ అటువంటి పనుల కోసం యూనివర్సల్ రేపర్ స్క్రిప్ట్‌ను ప్రారంభిస్తాడు, ఇది బ్యాకప్ రిపోజిటరీ, మౌంట్ పాయింట్‌లు మరియు మనకు కావలసిన ప్రతిదాని యొక్క చెల్లుబాటును తనిఖీ చేస్తుంది, ఆపై బ్యాకప్ చేసి పాతదాన్ని శుభ్రపరుస్తుంది. పూర్తయిన బ్యాకప్ S3కి పంపబడుతుంది.

మేము ఈ పథకం ప్రకారం పని చేస్తాము - ఇది బాహ్య AWS ప్రొవైడర్ లేదా రష్యన్ సమానమైనది (ఇది వేగవంతమైనది మరియు డేటా రష్యన్ ఫెడరేషన్ నుండి నిష్క్రమించదు). లేదా మేము ఈ ప్రయోజనాల కోసం క్లయింట్ కోసం అతని సైట్‌లో ప్రత్యేక మినియో క్లస్టర్‌ను ఇన్‌స్టాల్ చేస్తాము. క్లయింట్ తమ సర్క్యూట్ నుండి డేటాను వదిలివేయకూడదనుకున్నప్పుడు మేము సాధారణంగా భద్రతా కారణాల దృష్ట్యా దీన్ని చేస్తాము.

మేము ssh ద్వారా బ్యాకప్ పంపే లక్షణాన్ని ఉపయోగించలేదు. ఇది భద్రతను జోడించదు మరియు S3 ప్రొవైడర్ యొక్క నెట్‌వర్క్ సామర్థ్యాలు మా ఒక ssh మెషీన్ కంటే చాలా ఎక్కువ.

మీ స్థానిక మెషీన్‌ను హ్యాకర్ నుండి రక్షించడానికి, అతను S3లో డేటాను తొలగించగలడు కాబట్టి, మీరు తప్పనిసరిగా సంస్కరణను ప్రారంభించాలి.
బ్యాకప్ ఎల్లప్పుడూ బ్యాకప్‌ను గుప్తీకరిస్తుంది.

బోర్గ్‌లో ఎన్‌క్రిప్ట్ చేయని మోడ్ ఉంది none, కానీ మేము దీన్ని ఆన్ చేయమని గట్టిగా సిఫార్సు చేయము. ఈ మోడ్‌లో, ఎన్‌క్రిప్షన్ ఉండదు, కానీ ఏమి వ్రాయబడుతుందో చెక్‌సమ్ లెక్కించబడదు, అంటే సమగ్రతను సూచికలను ఉపయోగించి పరోక్షంగా మాత్రమే తనిఖీ చేయవచ్చు.

ప్రత్యేక షెడ్యూలర్ సూచికలు మరియు కంటెంట్ యొక్క సమగ్రత కోసం బ్యాకప్‌లను తనిఖీ చేస్తుంది. చెక్ నెమ్మదిగా మరియు పొడవుగా ఉంటుంది, కాబట్టి మేము దానిని నెలకు ఒకసారి విడిగా అమలు చేస్తాము. దీనికి చాలా రోజులు పట్టవచ్చు.

రష్యన్ భాషలో చదవండి

ప్రధాన విధులు

• prepare శిక్షణ
• testcheck సంసిద్ధత తనిఖీ
• maincommand ముఖ్య జట్టు
• forcepostscript ఒక ఫంక్షన్ ముగింపులో లేదా లోపం ద్వారా అమలు చేయబడుతుంది. విభజనను అన్‌మౌంట్ చేయడానికి మేము దానిని ఉపయోగిస్తాము.

సేవా విధులు

• cleanup మేము లోపాలను రికార్డ్ చేస్తాము లేదా లాగ్ ఫైల్‌ను చెరిపివేస్తాము.
• checklog లోపంతో లైన్ సంభవించినందుకు లాగ్‌ను అన్వయించండి.
• ret నిష్క్రమణ హ్యాండ్లర్.
• checktimeout సమయం ముగిసింది కోసం తనిఖీ చేయండి.

పర్యావరణ

• VERBOSE=1 మేము వెంటనే స్క్రీన్‌పై లోపాలను ప్రదర్శిస్తాము (stdout).
• SAVELOGSONSUCCES=1 విజయంపై లాగ్‌ను సేవ్ చేయండి.
• INIT_REPO_IF_NOT_EXIST=1 అది ఉనికిలో లేకుంటే రిపోజిటరీని సృష్టించండి. డిఫాల్ట్‌గా నిలిపివేయబడింది.
• TIMEOUT ప్రధాన ఆపరేషన్ కోసం గరిష్ట సమయం. మీరు దీన్ని చివరలో 'm', 'h' లేదా 'd'గా సెట్ చేయవచ్చు.

పాత కాపీల కోసం నిల్వ మోడ్. డిఫాల్ట్:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

స్క్రిప్ట్ లోపల వేరియబుల్స్

• ERROR_STRING - లోపం కోసం చెక్ ఇన్ లాగ్ కోసం స్ట్రింగ్.
• EXTRACT_ERROR_STRING — లోపం ఉంటే షో స్ట్రింగ్ కోసం వ్యక్తీకరణ.
• KILL_TIMEOUT_SIGNAL - గడువు ముగిసినట్లయితే చంపడానికి సంకేతం.
• TAIL - స్క్రీన్‌పై ఎన్ని స్ట్రింగ్‌లు ఎర్రర్‌లు ఉన్నాయి.
• COLORMSG — సందేశం రంగు (డిఫాల్ట్ పసుపు).

Wordpress అని పిలువబడే ఆ స్క్రిప్ట్‌కు షరతులతో కూడిన పేరు ఉంది, దాని ట్రిక్ ఏమిటంటే ఇది mysql డేటాబేస్‌ను కూడా బ్యాకప్ చేస్తుంది. ఇది సింగిల్-నోడ్ Nexcloud ఇన్‌స్టాలేషన్‌ల కోసం ఉపయోగించబడుతుంది, ఇక్కడ మీరు డేటాబేస్‌ను బ్యాకప్ చేయవచ్చు. సౌలభ్యం ఏమిటంటే, ప్రతిదీ ఒకే చోట ఉండటమే కాదు, డేటాబేస్ యొక్క కంటెంట్‌లు కూడా ఫైల్‌ల కంటెంట్‌లకు దగ్గరగా ఉంటాయి, ఎందుకంటే సమయ వ్యత్యాసం తక్కువగా ఉంటుంది.

రెస్టిక్ vs బోర్గ్

బోర్గ్ మరియు రెస్టిక్ మధ్య పోలికలు కూడా ఉన్నాయి ఇక్కడ హబ్రేలో, మరియు మేము మరొకదాన్ని తయారు చేసే పనిని కలిగి లేము, కానీ మా స్వంతం. ఇది మా డేటాపై, మా ప్రత్యేకతలతో ఎలా కనిపిస్తుందనేది మాకు ముఖ్యం. మేము వాటిని తీసుకువస్తాము.

మా ఎంపిక ప్రమాణాలు, ఇప్పటికే పేర్కొన్న వాటికి అదనంగా (డిప్లికేషన్, ఫాస్ట్ రికవరీ మొదలైనవి):

• అసంపూర్తిగా పనికి ప్రతిఘటన. కిల్ -9 కోసం తనిఖీ చేయండి.
• డిస్క్‌లో పరిమాణం.
• వనరుల అవసరం (CPU, మెమరీ).
• నిల్వ చేసిన బొబ్బల పరిమాణం.
• S3తో పని చేస్తున్నారు
• సమగ్రత తనిఖీ.

పరీక్ష కోసం, మేము నిజమైన డేటాతో ఒక క్లయింట్‌ని తీసుకున్నాము మరియు మొత్తం పరిమాణం 1,6 TB.
షరతులు.

S3తో నేరుగా ఎలా పని చేయాలో బోర్గ్‌కు తెలియదు మరియు మేము డిస్క్‌ను ఫ్యూజ్‌గా మౌంట్ చేసాము మూర్ఖులు. Restic దానిని S3కి పంపింది.

గూఫీలు ​​చాలా త్వరగా మరియు బాగా పనిచేస్తాయి మరియు ఉన్నాయి డిస్క్ కాష్ మాడ్యూల్, ఇది పనిని మరింత వేగవంతం చేస్తుంది. ఇది బీటా దశలో ఉంది మరియు స్పష్టంగా చెప్పాలంటే, పరీక్షల సమయంలో (ఇతరులు) డేటా నష్టంతో మేము క్రాష్ అయ్యాము. కానీ సౌలభ్యం ఏమిటంటే, బ్యాకప్ విధానానికి ఎక్కువ చదవడం అవసరం లేదు, కానీ ఎక్కువగా రాయడం అవసరం, కాబట్టి మేము సమగ్రత తనిఖీల సమయంలో మాత్రమే కాష్‌ని ఉపయోగిస్తాము.

నెట్‌వర్క్ ప్రభావాన్ని తగ్గించడానికి, మేము స్థానిక ప్రొవైడర్‌ని ఉపయోగించాము - Yandex క్లౌడ్.

పోలిక పరీక్ష ఫలితాలు.

• తదుపరి పునఃప్రారంభంతో కిల్ -9 రెండూ విజయవంతమయ్యాయి.
• డిస్క్‌లో పరిమాణం. బోర్గ్ కుదించవచ్చు, కాబట్టి ఫలితాలు ఆశించిన విధంగా ఉంటాయి.

బ్యాకపర్
పరిమాణం

బోర్గ్
562Gb

రెస్టిక్
628Gb

• CPU ద్వారా
  బోర్గ్ కూడా డిఫాల్ట్ కంప్రెషన్‌తో తక్కువ వినియోగిస్తుంది, కానీ అది గూఫీస్ ప్రక్రియతో కలిసి మూల్యాంకనం చేయాలి. మొత్తంగా, అవి ఒకే టెస్ట్ వర్చువల్ మెషీన్‌లో పోల్చదగినవి మరియు దాదాపు 1,2 కోర్లను ఉపయోగించుకుంటాయి.
• జ్ఞాపకశక్తి. రెస్టిక్ సుమారు 0,5GB, బోర్గ్ సుమారు 200MB. కానీ సిస్టమ్ ఫైల్ కాష్‌తో పోలిస్తే ఇదంతా చాలా తక్కువ. కాబట్టి ఎక్కువ మెమరీని కేటాయించడం మంచిది.
• బొట్టు పరిమాణంలో వ్యత్యాసం అద్భుతమైనది.

బ్యాకపర్
పరిమాణం

బోర్గ్
సుమారు 500MB

రెస్టిక్
సుమారు 5MB

• Restic యొక్క S3 తో అనుభవం అద్భుతమైనది. గూఫీస్ ద్వారా బోర్గ్‌తో పని చేయడం వల్ల ఎటువంటి ప్రశ్నలు తలెత్తవు, అయితే కాష్‌ని పూర్తిగా రీసెట్ చేయడానికి బ్యాకప్ పూర్తయిన తర్వాత umount చేయడం మంచిది అని గుర్తించబడింది. S3 యొక్క ప్రత్యేకత ఏమిటంటే, అండర్-పంప్ చేయబడిన భాగాలు బకెట్‌కి ఎప్పటికీ పంపబడవు, అంటే అసంపూర్ణంగా నింపబడిన డేటా పెద్ద నష్టానికి దారి తీస్తుంది.
• సమగ్రత తనిఖీ రెండు సందర్భాల్లోనూ బాగా పనిచేస్తుంది, కానీ వేగం గణనీయంగా భిన్నంగా ఉంటుంది.
  రెస్టిక్ గంటలు.
  బోర్గ్, 100GB SSD ఫైల్ కాష్‌తో – గంటలు.డేటా స్థానిక డిస్క్‌లో ఉంటే దాదాపు అదే వేగం ఫలితం.
  బోర్గ్ కాష్ లేకుండా S3 నుండి నేరుగా చదువుతుంది గంటలు. చాలా పొడవుగా ఉంది.

బాటమ్ లైన్ ఏమిటంటే, బోర్గ్ కుదించగలదు మరియు పెద్ద బ్లాబ్‌లను కలిగి ఉంటుంది - ఇది S3లో నిల్వ మరియు GET/PUT కార్యకలాపాలను చౌకగా చేస్తుంది. కానీ ఇది మరింత సంక్లిష్టమైన మరియు నెమ్మదిగా ధృవీకరణ ఖర్చుతో వస్తుంది. రికవరీ వేగం విషయానికొస్తే, మేము ఎటువంటి తేడాను గమనించలేదు. Restic తదుపరి బ్యాకప్‌లను (మొదటి తర్వాత) కొంచెం ఎక్కువ సమయం తీసుకుంటుంది, కానీ గణనీయంగా ఉండదు.

ఎంపికలో చివరిది కానీ సంఘం యొక్క పరిమాణం.

మరియు మేము బోర్గ్‌ని ఎంచుకున్నాము.

కుదింపు గురించి కొన్ని మాటలు

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

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

బోర్గ్ బోనస్ కంప్రెషన్ మోడ్‌ను కలిగి ఉంది - ఫైల్ అధిక ఎంట్రోపీని కలిగి ఉంటే, అప్పుడు కుదింపు అస్సలు వర్తించదు, ఇది వేగాన్ని పెంచుతుంది. సృష్టించేటప్పుడు ఎంపిక ద్వారా ప్రారంభించబడింది
-C auto,zstd
zstd అల్గోరిథం కోసం
కాబట్టి ఈ ఎంపికతో, డిఫాల్ట్ కంప్రెషన్‌తో పోల్చితే, మేము పొందాము
వరుసగా 560Gb మరియు 562Gb. ఎగువ ఉదాహరణ నుండి డేటా, నేను మీకు గుర్తు చేస్తాను, కుదింపు లేకుండా ఫలితం 628Gb. 2GB వ్యత్యాసం యొక్క ఫలితం మమ్మల్ని కొంత ఆశ్చర్యపరిచింది, అయితే మేము దానిని ఎంచుకుంటామని అనుకున్నాము. auto,zstd.

బ్యాకప్ ధృవీకరణ పద్ధతి

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

అదే పథకాన్ని ఉపయోగించి, మేము యాంటీవైరస్తో ఫైళ్లను తనిఖీ చేస్తాము (వాస్తవానికి తర్వాత). అన్నింటికంటే, వినియోగదారులు Nextcloudకి విభిన్న విషయాలను అప్‌లోడ్ చేస్తారు మరియు ప్రతి ఒక్కరికీ యాంటీవైరస్ ఉండదు. పోయడం సమయంలో తనిఖీలు నిర్వహించడం చాలా సమయం పడుతుంది మరియు వ్యాపారంలో జోక్యం చేసుకుంటుంది.

విభిన్న ట్యాగ్‌లతో విభిన్న నోడ్‌లలో రన్నర్‌లను అమలు చేయడం ద్వారా స్కేలబిలిటీ సాధించబడుతుంది.
మా పర్యవేక్షణ ఒక విండోలో GitLab API ద్వారా బ్యాకప్ స్టేటస్‌లను సేకరిస్తుంది; అవసరమైతే, సమస్యలు సులభంగా గుర్తించబడతాయి మరియు సులభంగా స్థానికీకరించబడతాయి.

తీర్మానం

ఫలితంగా, మేము బ్యాకప్‌లను తయారు చేస్తాము, మా బ్యాకప్‌లు చెల్లుబాటు అవుతాయని, వాటితో తలెత్తే సమస్యలు చాలా తక్కువ సమయం తీసుకుంటాయని మరియు డ్యూటీ అడ్మినిస్ట్రేటర్ స్థాయిలో పరిష్కరించబడతాయని మాకు ఖచ్చితంగా తెలుసు. tar.gz లేదా Baculaతో పోలిస్తే బ్యాకప్‌లు చాలా తక్కువ స్థలాన్ని తీసుకుంటాయి.

మూలం: www.habr.com