GitLab ትልልቅ የNextCloud ማከማቻዎችን ምትኬ እንዲያስቀምጡ እንዴት እንደሚያግዝዎት

ሃይ ሀብር!

ዛሬ የ Nextcloud ማከማቻዎችን በተለያዩ ውቅሮች ውስጥ ትልቅ የውሂብ ምትኬን በራስ-ሰር ስለማስኬድ ያለን ልምድ ማውራት እፈልጋለሁ። እኔ Molniya AK ውስጥ አገልግሎት ጣቢያ እሠራለሁ, እኛ IT ስርዓቶች ውቅር አስተዳደር ላይ የተሰማሩ, Nextcloud ውሂብ ማከማቻ ጥቅም ላይ ይውላል. ጨምሮ, ከተከፋፈለ መዋቅር ጋር, ከተደጋጋሚነት ጋር.

ከተጫኑት ልዩ ሁኔታዎች የሚነሱ ችግሮች ብዙ መረጃዎች መኖራቸው ነው. Nextcloud የሚሰጠው እትም፣ ድግግሞሽ፣ ተጨባጭ ምክንያቶች እና ሌሎችም ብዙ ብዜቶችን ይፈጥራል።

prehistory

Nextcloudን በሚያስተዳድሩበት ጊዜ ውሂቡ ዋጋ ያለው ስለሆነ መመስጠር ያለበት ውጤታማ ምትኬን የማደራጀት አጣዳፊ ችግር አለ።

የመጠባበቂያ ቅጂዎችን በእኛ ቦታ ወይም በደንበኛው ከ Nextcloud በተለየ ማሽኖቻቸው ላይ ለማከማቸት አማራጮችን እናቀርባለን ፣ ይህም ተለዋዋጭ አውቶማቲክ የአስተዳደር አቀራረብን ይፈልጋል።

ብዙ ደንበኞች አሉ, ሁሉም የተለያዩ ውቅሮች ያላቸው, እና ሁሉም በጣቢያዎቻቸው ላይ እና የራሳቸው ባህሪያት ያላቸው. እዚህ የመደበኛ ቴክኒካል ቴክኒኩ ሙሉው ጣቢያው የእርስዎ ነው, እና ምትኬዎች ከዘውድ የተሠሩ ናቸው, በትክክል አይመጥንም.

በመጀመሪያ የግብአት ውሂቡን እንይ። ያስፈልገናል፡-

• ከአንድ መስቀለኛ መንገድ ወይም ከበርካታ አንፃር ሚዛን። ለትላልቅ ጭነቶች ሚኒዮ እንደ ማከማቻ እንጠቀማለን።
• ስለ ምትኬ ችግሮች ይወቁ።
• ከደንበኞች እና/ወይም ከኛ ጋር ምትኬን መያዝ አለቦት።
• ችግሮችን በፍጥነት እና በቀላሉ ይፍቱ.
• ደንበኞች እና ተከላዎች አንዳቸው ከሌላው በጣም የተለዩ ናቸው - ተመሳሳይነት ማግኘት አይቻልም.
• የመልሶ ማግኛ ፍጥነት በሁለት ሁኔታዎች ዝቅተኛ መሆን አለበት፡ ሙሉ ማገገም (አደጋ)፣ አንድ አቃፊ በስህተት ተሰርዟል።
• ማባዛት ያስፈልጋል።

የመጠባበቂያ ቅጂዎችን የማስተዳደር ችግር ለመፍታት GitLabን ሰክረናል። የበለጠ የሚንከባለል።

እርግጥ ነው፣ እንዲህ ያለውን ችግር ለመፍታት የመጀመሪያው አይደለንም፣ ነገር ግን የሥቃይ ልምዳችን ተግባራዊ ሊሆን ስለሚችል እሱን ለመካፈል ዝግጁ መሆናችንን ይሰማናል።

ኩባንያችን የክፍት ምንጭ ፖሊሲን ስለተቀበለ፣ ክፍት ምንጭ መፍትሄ እየፈለግን ነበር። በተራው፣ እድገቶቻችንን እናካፍላለን እና እንለጥፋቸዋለን። ለምሳሌ በ GitHub ላይ አለ። የእኛ ተሰኪ ለ Nextcloud, ለደንበኞች የምናስቀምጠው, በአጋጣሚ ወይም ሆን ተብሎ ከተሰረዘ የውሂብ ደህንነትን ይጨምራል.

የመጠባበቂያ መሳሪያዎች

የመጠባበቂያ ፈጠራ መሳሪያን በመምረጥ የመፍትሄ ዘዴዎችን መፈለግ ጀመርን.

መደበኛ tar + gzip በደንብ አይሰራም - መረጃው የተባዛ ነው። አንድ ጭማሪ ብዙውን ጊዜ በእውነቱ በጣም ጥቂት ለውጦችን ይይዛል፣ እና አብዛኛው ተመሳሳይ ፋይል ውስጥ ያለው ውሂብ ይደገማል።
ሌላ ችግር አለ - የተከፋፈለ የውሂብ መጋዘን ድግግሞሽ. ሚኒዮ እንጠቀማለን እና ውሂቡ በመሰረታዊነት ብዙ ነው። ወይም በራሱ ሚኒዮ በኩል ምትኬ መስራት አስፈላጊ ነበር - ይጫኑት እና በፋይል ስርዓቱ መካከል ያሉትን ሁሉንም ስፔሰርስ ይጠቀሙ ፣ እና ምንም ያነሰ አስፈላጊ ፣ ስለ አንዳንድ ባልዲዎች እና ሜታ-መረጃ የመርሳት አደጋ አለ ። ወይም ማባዛትን ተጠቀም።

ብዜት ያላቸው የመጠባበቂያ መሳሪያዎች በክፍት ምንጭ ውስጥ ይገኛሉ (እዚያ ነበሩ መጣጥፎች ስለዚህ ጭብጥ) እና የመጨረሻ እጩዎቻችን ነበሩ። Borg и ገጠር. ከዚህ በታች ስላሉት የሁለቱ አፕሊኬሽኖች ንጽጽር፣ አሁን ግን አጠቃላይ ዕቅዱን እንዴት እንዳደራጀን እንነጋገር።

የመጠባበቂያ አስተዳደር

ቦርግ እና ሬስቲክ ጥሩ ናቸው፣ ነገር ግን ሁለቱም ምርቶች የተማከለ ቁጥጥር ዘዴ የላቸውም። ለአስተዳደር እና ለቁጥጥር ዓላማ, ቀደም ሲል የተተገበርነውን መሳሪያ መርጠናል, ያለሱ ስራችንን አውቶማቲክን ጨምሮ መገመት አንችልም - ይህ በጣም የታወቀው CI / CD - GitLab.

ሀሳቡ እንደሚከተለው ነው-የ Nextcloud መረጃን የሚያከማች የጊትላብ ሯጭ በእያንዳንዱ መስቀለኛ መንገድ ላይ ይደረጋል። ሯጩ የመጠባበቂያ ሂደቱን የሚከታተል የታቀደ ስክሪፕት ይሰራል እና ቦርግ ወይም ሬስቲክ ይጀምራል።

ምን አገኘን? የአፈፃፀም ግብረመልስ ፣ በለውጦች ላይ ምቹ ቁጥጥር ፣ ስህተት ከተፈጠረ ዝርዝሮች።

እዚህ እዚህ github ላይ ለተለያዩ ስራዎች የስክሪፕት ምሳሌዎችን ለጥፈናል, እና በውጤቱም, ከ Nextcloud ብቻ ሳይሆን ከሌሎች ብዙ አገልግሎቶች መጠባበቂያ ጋር አያያዝነው. በእጆችዎ ማዋቀር ካልፈለጉ (እና እኛ አንፈልግም) እና .gitlab-ci.yml መርሐግብር አዘጋጅም አለ።

የጊትላብ ኤፒአይ ገና የCI/ሲዲ ጊዜ ማብቂያን የመቀየር ችሎታ የለውም፣ እና እዚያ ትንሽ ነው። መጨመር አለበት በላቸው 1d.

GitLab, እንደ እድል ሆኖ, በቁርጠኝነት ላይ ብቻ ሳይሆን በጊዜ መርሐግብር ላይ ብቻ ሊሄድ ይችላል, እኛ የምንፈልገው ይህ ነው.

አሁን ስለ መጠቅለያው ጽሑፍ።

ለዚህ ስክሪፕት የሚከተሉትን ቅድመ ሁኔታዎች አዘጋጅተናል።

• በተመሳሳይ ተግባር በሁለቱም ሯጭ እና ከኮንሶሉ በእጅ መነሳት አለበት።
• የስህተት ተቆጣጣሪዎች ሊኖሩ ይገባል:
• የመመለሻ ኮድ.
• በምዝግብ ማስታወሻው ውስጥ መስመር ይፈልጉ. ለምሳሌ, ለእኛ, ስህተት ፕሮግራሙ ገዳይ እንደሆነ የማይቆጥረው መልእክት ሊሆን ይችላል.
• የጊዜ ገደብ አያያዝ. የማስፈጸሚያ ጊዜ ምክንያታዊ መሆን አለበት.
• ዝርዝር መዝገብ እንፈልጋለን። ግን ስህተት ሲፈጠር ብቻ።
• ከመጀመርዎ በፊት በርካታ ሙከራዎችም ይከናወናሉ.
• በድጋፍ ሂደቱ ወቅት ጠቃሚ ሆኖ ያገኘናቸው አነስተኛ ምቾት ባህሪያት፡-
• መጀመሪያ እና መጨረሻ የተመዘገቡት በአከባቢው ማሽን syslog ውስጥ ነው። ይህ የስርዓት ስህተቶችን እና የመጠባበቂያ ክዋኔን ለማገናኘት ይረዳል.
• የስህተት ምዝግብ ማስታወሻው ክፍል ፣ ማንኛውም ፣ ወደ stdout ሲታተም ፣ አጠቃላይ ምዝግብ ማስታወሻው ወደተለየ ፋይል ይፃፋል። ወዲያውኑ CI ን ለመመልከት እና ስህተቱን ቀላል ከሆነ ለመገምገም ምቹ ነው.
• የማረም ሁነታዎች።

ሙሉ ምዝግብ ማስታወሻው በ GitLab ውስጥ እንደ ቅርስ ተቀምጧል, ምንም ስህተት ከሌለ, ምዝግብ ማስታወሻው ይሰረዛል. ስክሪፕቱ የተፃፈው በባሽ ነው።

በክፍት ምንጭ ላይ ማንኛውንም አስተያየት እና አስተያየት ለመመልከት ደስተኞች ነን - እንኳን ደህና መጡ።

ይህን ሥራ የሚያደርገው እንዴት ነው?

ባሽ አስፈፃሚ ያለው ሯጭ በመጠባበቂያ መስቀለኛ መንገድ ላይ ይጀምራል። እንደ መርሐግብር አውጪው, የ CI / ሲዲ ሥራ በልዩ መታጠፊያ ውስጥ ተጀምሯል. ሯጩ ለእንደዚህ አይነት ስራዎች ሁለንተናዊ መጠቅለያ ስክሪፕት ያስጀምራል፣ የመጠባበቂያ ማከማቻውን ትክክለኛነት ያረጋግጣል፣ ነጥቦቹን ይሰቀሉ እና የምንፈልገውን ሁሉ ይደግፋሉ እና አሮጌውን ያጸዳሉ። የተጠናቀቀው ምትኬ ራሱ ወደ 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 - የመልእክት ቀለም (ነባሪ ቢጫ)።

ዎርድፕረስ ተብሎ የሚጠራው ስክሪፕት ሁኔታዊ ተብሎ ይጠራል ፣ የእሱ ብልሃት ደግሞ የ mysql ዳታቤዝ ምትኬን መያዙ ነው። ይህ ማለት ለነጠላ መስቀለኛ መንገድ የNexcloud ጭነቶች ጥቅም ላይ ሊውል ይችላል፣ እዚያም የውሂብ ጎታውን በተመሳሳይ ጊዜ ምትኬ ማስቀመጥ ይችላሉ። ምቾቱ ሁሉም ነገር በአንድ ቦታ ላይ ብቻ አይደለም, ነገር ግን የውሂብ ጎታው ይዘቶች ከፋይሎቹ ይዘቶች ጋር ቅርብ ናቸው, ምክንያቱም የጊዜ ልዩነት አነስተኛ ስለሆነ.

ሬስቲክ vs ቦርግ

ጨምሮ የቦርግ እና ሬስቲክ ንጽጽሮች አሉ። እዚህ ሀበሬ ላይእኛ ደግሞ የራሳችንን እንጂ ሌላ የመሥራት ሥራ አልነበረንም። በእኛ መረጃ ላይ እንዴት እንደሚታይ ከእኛ ዝርዝር ጉዳዮች ጋር ለእኛ አስፈላጊ ነበር። እናመጣቸዋለን።

የእኛ ምርጫ መስፈርቶች፣ ቀደም ሲል ከተጠቀሱት (ማባዛት፣ ፈጣን ማገገም፣ ወዘተ) በተጨማሪ፡

• በሂደት ላይ ለመስራት የመቋቋም ችሎታ። ለመግደል ያረጋግጡ -9.
• የዲስክ መጠን.
• በንብረቶች ላይ ፍላጎት (ሲፒዩ, ማህደረ ትውስታ).
• የተከማቹ ነጠብጣቦች መጠን.
• ከ S3 ጋር በመስራት ላይ.
• የታማኝነት ማረጋገጫ።

ለሙከራ አንድ ደንበኛ ትክክለኛ መረጃ ያለው እና አጠቃላይ መጠኑ 1,6 ቴባ ወስደናል።
ሁኔታዎች

ቦርግ ከ S3 ጋር በቀጥታ አይሰራም, እና እንደ ፊውዝ ዲስክ ጫንነው, በ ጎፊዎች. ሬስቲክ ወደ ራሱ S3 ተልኳል።

Goofys በጣም በፍጥነት እና በደንብ ይሰራል, እና አሉ የዲስክ መሸጎጫ ሞጁልነገሮችን የበለጠ ያፋጥናል. በቅድመ-ይሁንታ ደረጃ ላይ ነው፣ እና እውነቱን ለመናገር፣ በፈተናዎች (ሌሎች) መረጃ መጥፋት ምክንያት ከእኛ ጋር ተሰናክሏል። ነገር ግን ምቾቱ የመጠባበቂያ ሂደቱ ራሱ ብዙ ማንበብ አያስፈልገውም, ነገር ግን በአብዛኛው መፃፍ ነው, ስለዚህ መሸጎጫውን የምንጠቀመው በንፅህና ማረጋገጫ ጊዜ ብቻ ነው.

የአውታረ መረቡ ተጽእኖን ለመቀነስ, የአካባቢያዊ አቅራቢን - Yandex ክላውድ እንጠቀማለን.

የንጽጽር የፈተና ውጤቶች.

• Kill -9 ከተጨማሪ ዳግም ማስጀመር ጋር ሁለቱም ስኬታማ ነበሩ።
• የዲስክ መጠን. ቦርግ እንዴት መጭመቅ እንዳለበት ያውቃል, ስለዚህ ውጤቱ ይጠበቃል.

ምትኬ
ልክ

Borg
562Gb

ገጠር
628Gb

• በሲፒዩ
  በራሱ, ቦርግ በነባሪ መጭመቅ ትንሽ ይበላል, ነገር ግን ከጎፊዎች ሂደት ጋር መገምገም አለበት. በጠቅላላው፣ የሚነጻጸሩ ናቸው እና በተመሳሳይ የሙከራ ቨርቹዋል ማሽን ላይ ወደ 1,2 ኮሮች ይጠቀማሉ።
• ማህደረ ትውስታ. Restic ስለ 0,5Gb፣ Borg 200Mb አካባቢ። ነገር ግን ይህ ሁሉ ከስርዓቱ የፋይል መሸጎጫ ጋር ሲወዳደር እዚህ ግባ የሚባል አይደለም። ስለዚህ ተጨማሪ ማህደረ ትውስታን ለመመደብ ተፈላጊ ነው.
• የብሎብስ መጠን ያለው ልዩነት በጣም አስደናቂ ነበር.

ምትኬ
ልክ

Borg
ወደ 500Mb

ገጠር
ወደ 5Mb

• ከሬስቲክ ኤስ 3 ጋር መስራት ጥሩ ነው። በጎፊስ በኩል የቦርግ ስራ ምንም አይነት ጥያቄ አይፈጥርም, ነገር ግን መሸጎጫውን ሙሉ በሙሉ እንደገና ለማስጀመር በመጠባበቂያው መጨረሻ ላይ umount ማድረግ እንደሚፈለግ ተስተውሏል. የS3 ልዩነት ከወረዱ በታች የወረዱ ቁርጥራጮች በጭራሽ ወደ ባልዲው አይላኩም፣ ይህ ማለት ያልተሟላ መረጃ ወደ ከፍተኛ ጉዳት ይመራል ማለት ነው።
• የንጹህነት ማረጋገጫው በሁለቱም ሁኔታዎች በደንብ ይሰራል, ነገር ግን ፍጥነቱ በከፍተኛ ሁኔታ ይለያያል.
  እረፍት - 3,5 ሰዓታት.
  ቦርግ፣ ከ100GB SSD ፋይል መሸጎጫ ጋር - 5 ሰዓታትመረጃው በአካባቢው ዲስክ ላይ ከሆነ ከፍጥነት አንፃር ተመሳሳይ ውጤት.
  ቦርግ ያለ መሸጎጫ በቀጥታ ከ S3 ያነባል። 33 ሰዓታት. በሚያስደንቅ ሁኔታ ረጅም።

ዋናው ነገር ቦርግ መጭመቅ ይችላል እና ትላልቅ ነጠብጣቦች አሉት - ይህም ማከማቻ እና GET/PUT ስራዎችን በ S3 ርካሽ ያደርገዋል። ነገር ግን ይህ ይበልጥ ውስብስብ እና ቀርፋፋ ቼክ ዋጋ ላይ ይመጣል. የመልሶ ማግኛ ፍጥነትን በተመለከተ, ልዩነት አላስተዋልንም. Restic ተከታይ መጠባበቂያዎችን (ከመጀመሪያው በኋላ) ትንሽ ረዘም ያለ ያደርገዋል, ነገር ግን ጉልህ አይደለም.

በምርጫው ውስጥ የመጨረሻው አይደለም የማህበረሰቡ መጠን ነበር.

እና ቦርግ መረጥን.

ስለ መጨናነቅ ጥቂት ቃላት

ቦርግ በጦር ጦሩ ውስጥ ታላቅ አዲስ የመጭመቂያ ስልተ-ቀመር አለው - zstd። የመጨመቂያው ጥራት ከ gzip የከፋ አይደለም, ነገር ግን በጣም ፈጣን ነው. እና ከነባሪው lz4 ጋር በፍጥነት ያወዳድሩ።

ለምሳሌ፣ የ MySQL ዳታቤዝ መጣያ በተመሳሳይ ፍጥነት ከ lz4 በሁለት እጥፍ ይጨመቃል። ነገር ግን፣ በእውነተኛ መረጃ ላይ ያለው ልምድ በ Nextcloud node የመጨመቂያ ሬሾ ውስጥ በጣም ትንሽ ልዩነት እንዳለ ያሳያል።

Borg ይልቅ ጉርሻ መጭመቂያ ሁነታ አለው - ፋይሉ ትልቅ entropy ያለው ከሆነ, ከዚያም መጭመቂያ ምንም ተግባራዊ አይደለም, ይህም የሥራ ፍጥነት ይጨምራል. ሲፈጥሩ በአማራጭ የነቃ
-C auto,zstd
ለ zstd አልጎሪዝም
ስለዚህ ከዚህ አማራጭ ጋር, ከነባሪው መጨናነቅ ጋር ሲነጻጸር, አግኝተናል
560Gb እና 562Gb በቅደም ተከተል። ከላይ ባለው ምሳሌ ላይ ያለው መረጃ, ላስታውስዎት, ያለ ማመቅ, ውጤቱ 628Gb ነው. የ2ጂቢ ልዩነት ውጤት በጥቂቱ አስገርሞናል፣ ግን ለማንኛውም እንደምንመርጥ አሰብን። 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 የተለያዩ ነገሮችን ይሰቅላሉ እና ሁሉም ሰው ጸረ-ቫይረስ የለውም። በሚፈስበት ጊዜ መፈተሽ ብዙ ጊዜ ይወስዳል እና በንግድ ስራ ላይ ጣልቃ ይገባል.

መጠነ-ሰፊነት በተለያዩ ኖዶች ላይ ሯጮችን በተለያዩ መለያዎች በመሮጥ ይገኛል ።
በእኛ ክትትል፣ የመጠባበቂያ ሁኔታዎች በጊትላብ ኤፒአይ በአንድ መስኮት ይሰበሰባሉ፣ ካስፈለገም ችግሮቹ በቀላሉ ይስተዋላሉ፣ እና በቀላሉ የተተረጎሙ ናቸው።

መደምደሚያ

በውጤቱም, ምትኬዎችን እንደሰራን, የእኛ ምትኬዎች ትክክለኛ መሆናቸውን, በእነሱ ላይ የሚነሱ ችግሮች ትንሽ ጊዜ የሚወስዱ እና በአስተዳዳሪው በስራ ላይ ባለው ደረጃ መፍትሄ እንደሚያገኙ በእርግጠኝነት እናውቃለን. ምትኬዎች ከ tar.gz ወይም Bacula ጋር ሲነጻጸሩ ትንሽ ቦታ ይወስዳሉ።

ምንጭ: hab.com