બેકઅપ ભાગ 4: ઝેડબેકઅપ, રેસ્ટિક, બોર્ગબેકઅપની સમીક્ષા અને પરીક્ષણ

આ લેખ બેકઅપ સૉફ્ટવેરને ધ્યાનમાં લેશે જે, ડેટા સ્ટ્રીમને અલગ ઘટકો (હિસ્સામાં) માં તોડીને, એક ભંડાર બનાવે છે.

રિપોઝીટરી ઘટકોને વધુ સંકુચિત અને એનક્રિપ્ટ કરી શકાય છે, અને સૌથી અગત્યનું - પુનરાવર્તિત બેકઅપ પ્રક્રિયાઓ દરમિયાન - ફરીથી ઉપયોગમાં લેવાય છે.

આવા રીપોઝીટરીમાં બેકઅપ કોપી એ એકબીજા સાથે જોડાયેલા ઘટકોની નામવાળી સાંકળ છે, ઉદાહરણ તરીકે, વિવિધ હેશ કાર્યો પર આધારિત.

ત્યાં ઘણા સમાન ઉકેલો છે, હું 3 પર ધ્યાન કેન્દ્રિત કરીશ: zbackup, borgbackup અને restic.

અપેક્ષિત પરિણામો

બધા અરજદારોને એક અથવા બીજી રીતે રિપોઝીટરી બનાવવાની જરૂર હોવાથી, સૌથી મહત્વપૂર્ણ પરિબળો પૈકી એક રીપોઝીટરીના કદનો અંદાજ કાઢવો પડશે. આદર્શરીતે, તેનું કદ સ્વીકૃત પદ્ધતિ અનુસાર 13 જીબી કરતા વધુ ન હોવું જોઈએ, અથવા તેનાથી ઓછું - સારા ઑપ્ટિમાઇઝેશનને આધિન.

ટાર જેવા આર્કાઇવર્સનો ઉપયોગ કર્યા વિના, તેમજ rsync અને sshfs જેવા વધારાના ટૂલ્સ વિના ssh/sftp સાથે કામ કર્યા વિના, ફાઇલોની બેકઅપ નકલો સીધી બનાવવા માટે સક્ષમ થવું પણ ખૂબ ઇચ્છનીય છે.

બેકઅપ બનાવતી વખતે વર્તન:

1. રીપોઝીટરીનું કદ ફેરફારોના કદ જેટલું અથવા ઓછું હશે.
2. કમ્પ્રેશન અને/અથવા એન્ક્રિપ્શનનો ઉપયોગ કરતી વખતે ભારે CPU લોડની અપેક્ષા રાખવામાં આવે છે, અને જો બેકઅપ સ્ટોરેજ સર્વર પર આર્કાઇવિંગ અને/અથવા એન્ક્રિપ્શન પ્રક્રિયા ચાલી રહી હોય તો નેટવર્ક અને ડિસ્ક લોડ ખૂબ વધારે છે.
3. જો રીપોઝીટરી ક્ષતિગ્રસ્ત હોય, તો નવા બેકઅપ બનાવતી વખતે અને પુનઃસ્થાપિત કરવાનો પ્રયાસ કરતી વખતે વિલંબિત ભૂલ થવાની સંભાવના છે. રીપોઝીટરીની અખંડિતતાને સુનિશ્ચિત કરવા અથવા તેની અખંડિતતા તપાસવા માટે બિલ્ટ-ઇન ટૂલ્સનો ઉપયોગ કરવા માટે વધારાના પગલાંની યોજના કરવી જરૂરી છે.

ટાર સાથે કામ કરવું એ સંદર્ભ મૂલ્ય તરીકે લેવામાં આવે છે, જેમ કે અગાઉના લેખોમાંના એકમાં દર્શાવવામાં આવ્યું હતું.

zbackup પરીક્ષણ

zbackup ની સામાન્ય પદ્ધતિ એ છે કે પ્રોગ્રામ સમાન ડેટા ધરાવતા ઇનપુટ ડેટા સ્ટ્રીમ વિસ્તારોમાં શોધે છે, પછી વૈકલ્પિક રીતે તેને સંકુચિત કરે છે અને એનક્રિપ્ટ કરે છે, દરેક વિસ્તારને માત્ર એક જ વાર સાચવે છે.

ડીડુપ્લિકેશન હાલના ડેટા બ્લોક્સ સામે બાઇટ-બાય-બાઇટ મેચો તપાસવા માટે સ્લાઇડિંગ વિન્ડો સાથે 64-બીટ રિંગ હેશ ફંક્શનનો ઉપયોગ કરે છે (Rsync તેને કેવી રીતે અમલમાં મૂકે છે તેના જેવું જ).

મલ્ટિ-થ્રેડેડ lzma અને lzo નો ઉપયોગ કમ્પ્રેશન માટે થાય છે, અને aes એન્ક્રિપ્શન માટે. નવીનતમ સંસ્કરણો ભવિષ્યમાં રિપોઝીટરીમાંથી જૂના ડેટાને કાઢી નાખવાની ક્ષમતા ધરાવે છે.
પ્રોગ્રામ ન્યૂનતમ નિર્ભરતા સાથે C++ માં લખાયેલ છે. લેખક દેખીતી રીતે યુનિક્સ-વેથી પ્રેરિત હતા, તેથી પ્રોગ્રામ બેકઅપ બનાવતી વખતે stdin પર ડેટા સ્વીકારે છે, જ્યારે પુનઃસ્થાપિત કરતી વખતે stdout પર સમાન ડેટા સ્ટ્રીમ ઉત્પન્ન કરે છે. આમ, તમારા પોતાના બેકઅપ સોલ્યુશન્સ લખતી વખતે zbackup નો ઉપયોગ ખૂબ જ સારા "બિલ્ડીંગ બ્લોક" તરીકે થઈ શકે છે. ઉદાહરણ તરીકે, લેખના લેખકે આશરે 2014 થી હોમ મશીનો માટેના મુખ્ય બેકઅપ સાધન તરીકે આ પ્રોગ્રામનો ઉપયોગ કર્યો છે.

ડેટા સ્ટ્રીમ નિયમિત ટાર હશે જ્યાં સુધી અન્યથા જણાવવામાં ન આવે.

ચાલો જોઈએ કે પરિણામો શું છે:

કાર્યને 2 વિકલ્પોમાં તપાસવામાં આવ્યું હતું:

1. એક રીપોઝીટરી બનાવવામાં આવે છે અને સ્રોત ડેટા સાથે સર્વર પર zbackup લોંચ કરવામાં આવે છે, પછી રીપોઝીટરીની સામગ્રીઓ બેકઅપ સ્ટોરેજ સર્વરમાં સ્થાનાંતરિત થાય છે.
2. બેકઅપ સ્ટોરેજ સર્વર પર રીપોઝીટરી બનાવવામાં આવે છે, બેકઅપ સ્ટોરેજ સર્વર પર ssh દ્વારા zbackup લોન્ચ કરવામાં આવે છે, અને ડેટા તેને પાઇપ દ્વારા મોકલવામાં આવે છે.

પ્રથમ વિકલ્પના પરિણામો નીચે મુજબ હતા: 43m11s - જ્યારે એનક્રિપ્ટેડ રીપોઝીટરી અને lzma કોમ્પ્રેસરનો ઉપયોગ કરી રહ્યા હોય, 19m13s - જ્યારે કોમ્પ્રેસરને lzo સાથે બદલી રહ્યા હોય.

મૂળ ડેટા સાથે સર્વર પરનો ભાર નીચે મુજબ હતો (lzma સાથેનું ઉદાહરણ બતાવવામાં આવ્યું છે, lzo સાથે લગભગ સમાન ચિત્ર હતું, પરંતુ rsyncનો હિસ્સો સમયના એક ક્વાર્ટર જેટલો હતો):

તે સ્પષ્ટ છે કે આવી બેકઅપ પ્રક્રિયા પ્રમાણમાં દુર્લભ અને નાના ફેરફારો માટે જ યોગ્ય છે. ઝેડબેકઅપને 1 થ્રેડ સુધી મર્યાદિત રાખવાની પણ ખૂબ સલાહ આપવામાં આવે છે, અન્યથા ત્યાં ખૂબ જ વધારે CPU લોડ હશે, કારણ કે પ્રોગ્રામ બહુવિધ થ્રેડોમાં કામ કરવા માટે ખૂબ જ સારો છે. ડિસ્ક પરનો ભાર નાનો હતો, જે સામાન્ય રીતે આધુનિક ssd-આધારિત ડિસ્ક સબસિસ્ટમ સાથે ધ્યાનપાત્ર ન હોત. તમે રિપોઝીટરી ડેટાને રિમોટ સર્વર સાથે સિંક્રનાઇઝ કરવાની પ્રક્રિયાની શરૂઆત પણ સ્પષ્ટપણે જોઈ શકો છો. આ અભિગમનો ગેરલાભ એ સ્થાનિક રીપોઝીટરીનો સંગ્રહ છે અને પરિણામે, ડેટાનું ડુપ્લિકેશન.

વ્યવહારમાં વધુ રસપ્રદ અને લાગુ પડતો બીજો વિકલ્પ છે, બેકઅપ સ્ટોરેજ સર્વર પર સીધા જ zbackup ચલાવવું.

પ્રથમ, અમે lzma કોમ્પ્રેસર સાથે એન્ક્રિપ્શનનો ઉપયોગ કર્યા વિના ઓપરેશનનું પરીક્ષણ કરીશું:

દરેક ટેસ્ટ રનનો રનિંગ સમય:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

39m45 સે
40m20 સે
40m3 સે

7m36 સે
8m3 સે
7m48 સે

15m35 સે
15m48 સે
15m38 સે

જો તમે aes નો ઉપયોગ કરીને એન્ક્રિપ્શન સક્ષમ કરો છો, તો પરિણામો એકદમ નજીક છે:

એન્ક્રિપ્શન સાથે સમાન ડેટા પર ઓપરેટિંગ સમય:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

43m40 સે
44m12 સે
44m3 સે

8m3 સે
8m15 સે
8m12 સે

15m0 સે
15m40 સે
15m25 સે

જો એન્ક્રિપ્શનને lzo નો ઉપયોગ કરીને કમ્પ્રેશન સાથે જોડવામાં આવે છે, તો તે આના જેવું દેખાય છે:

કાર્યકારી કલાકો:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

18m2 સે
18m15 સે
18m12 સે

5m13 સે
5m24 સે
5m20 સે

8m48 સે
9m3 સે
8m51 સે

પરિણામી રીપોઝીટરીનું કદ 13GB પર પ્રમાણમાં સમાન હતું. આનો અર્થ એ છે કે ડીડુપ્લિકેશન યોગ્ય રીતે કાર્ય કરી રહ્યું છે. ઉપરાંત, પહેલાથી જ સંકુચિત ડેટા પર, lzo નો ઉપયોગ કરવાથી કુલ ઓપરેટિંગ સમયની દ્રષ્ટિએ નોંધપાત્ર અસર મળે છે, zbackup ડુપ્લીસીટી/ડુપ્લિકેટીની નજીક આવે છે, પરંતુ 2-5 ગણા લાઇબ્રસિંક પર આધારિત છે.

ફાયદા સ્પષ્ટ છે - બેકઅપ સ્ટોરેજ સર્વર પર ડિસ્ક જગ્યા બચાવવી. રીપોઝીટરી ચેકીંગ ટૂલ્સ માટે, zbackup ના લેખક તેમને પૂરા પાડતા નથી ફોલ્ટ-ટોલરન્ટ ડિસ્ક એરે અથવા ક્લાઉડ પ્રદાતાનો ઉપયોગ કરવાની ભલામણ કરવામાં આવે છે.

એકંદરે, ખૂબ જ સારી છાપ, એ હકીકત હોવા છતાં કે પ્રોજેક્ટ લગભગ 3 વર્ષથી સ્થિર છે (છેલ્લી સુવિધા વિનંતી લગભગ એક વર્ષ પહેલાં હતી, પરંતુ કોઈ પ્રતિસાદ વિના).

બોર્ગબેકઅપનું પરીક્ષણ

બોર્ગબેકઅપ એ એટિકનો ફોર્ક છે, જે zbackup જેવી જ બીજી સિસ્ટમ છે. python માં લખાયેલ, તેમાં zbackup જેવી જ ક્ષમતાઓની સૂચિ છે, પરંતુ વધુમાં તે આ કરી શકે છે:

• ફ્યુઝ દ્વારા બેકઅપ માઉન્ટ કરો
• રીપોઝીટરી સામગ્રીઓ તપાસો
• ક્લાયંટ-સર્વર મોડમાં કામ કરો
• ડેટા માટે વિવિધ કોમ્પ્રેસરનો ઉપયોગ કરો, તેમજ તેને સંકુચિત કરતી વખતે ફાઇલના પ્રકારનું હ્યુરિસ્ટિક નિર્ધારણ કરો.
• 2 એન્ક્રિપ્શન વિકલ્પો, aes અને બ્લેક
• માટે બિલ્ટ-ઇન ટૂલ

કામગીરી તપાસો

borgbackup બેન્ચમાર્ક crud ssh://backup_server/repo/path local_dir

પરિણામો નીચે મુજબ હતા:

CZ-BIG 96.51 MB/s (10 100.00 MB ઓલ-ઝીરો ફાઇલો: 10.36)
RZ-BIG 57.22 MB/s (10 100.00 MB ઓલ-ઝીરો ફાઇલો: 17.48)
UZ-BIG 253.63 MB/s (10 100.00 MB ઓલ-ઝીરો ફાઇલો: 3.94)
DZ-BIG 351.06 MB/s (10 100.00 MB ઓલ-ઝીરો ફાઇલો: 2.85)
CR-BIG 34.30 MB/s (10 100.00 MB રેન્ડમ ફાઇલો: 29.15 સે)
RR-BIG 60.69 MB/s (10 100.00 MB રેન્ડમ ફાઇલો: 16.48 સે)
UR-BIG 311.06 MB/s (10 100.00 MB રેન્ડમ ફાઇલો: 3.21 સે)
DR-BIG 72.63 MB/s (10 100.00 MB રેન્ડમ ફાઇલો: 13.77 સે)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB ઓલ-ઝીરો ફાઇલો: 9.21)
RZ-મધ્યમ 76.16 MB/s (1000 1.00 MB ઓલ-ઝીરો ફાઇલો: 13.13)
UZ-મધ્યમ 331.27 MB/s (1000 1.00 MB ઓલ-ઝીરો ફાઇલો: 3.02)
DZ-મધ્યમ 387.36 MB/s (1000 1.00 MB ઓલ-ઝીરો ફાઇલો: 2.58)
CR-મધ્યમ 37.80 MB/s (1000 1.00 MB રેન્ડમ ફાઇલો: 26.45 સે)
RR-મીડિયમ 68.90 MB/s (1000 1.00 MB રેન્ડમ ફાઇલો: 14.51 સે)
યુઆર-મીડિયમ 347.24 MB/s (1000 1.00 MB રેન્ડમ ફાઇલો: 2.88 સે)
DR-મીડિયમ 48.80 MB/s (1000 1.00 MB રેન્ડમ ફાઇલો: 20.49 સે)
CZ-SMALL 11.72 MB/s (10000 10.00 kB ઓલ-ઝીરો ફાઇલો: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB ઓલ-ઝીરો ફાઇલો: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB ઓલ-ઝીરો ફાઇલો: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB ઓલ-ઝીરો ફાઇલો: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB રેન્ડમ ફાઇલો: 14.60)
RR-SMALL 31.27 MB/s (10000 10.00 kB રેન્ડમ ફાઇલો: 3.20)
UR-SMALL 12.28 MB/s (10000 10.00 kB રેન્ડમ ફાઇલો: 8.14)
DR-SMALL 18.78 MB/s (10000 10.00 kB રેન્ડમ ફાઇલો: 5.32)

પરીક્ષણ કરતી વખતે, કમ્પ્રેશન હ્યુરિસ્ટિક્સનો ઉપયોગ ફાઇલ પ્રકાર (કમ્પ્રેશન ઓટો) નક્કી કરવા માટે કરવામાં આવશે, અને પરિણામો નીચે મુજબ હશે:

પ્રથમ, ચાલો તપાસ કરીએ કે તે એન્ક્રિપ્શન વિના કેવી રીતે કાર્ય કરે છે:

કાર્યકારી કલાકો:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

4m6 સે
4m10 સે
4m5 સે

56s
58s
54s

1m26 સે
1m34 સે
1m30 સે

જો તમે રીપોઝીટરી અધિકૃતતા (પ્રમાણિત મોડ) સક્ષમ કરો છો, તો પરિણામો નજીક હશે:

કાર્યકારી કલાકો:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

4m11 સે
4m20 સે
4m12 સે

1m0 સે
1m3 સે
1m2 સે

1m30 સે
1m34 સે
1m31 સે

જ્યારે aes એન્ક્રિપ્શન સક્રિય કરવામાં આવ્યું હતું, ત્યારે પરિણામો વધુ બગડ્યા ન હતા:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

4m55 સે
5m2 સે
4m58 સે

1m0 સે
1m2 સે
1m0 સે

1m49 સે
1m50 સે
1m50 સે

અને જો તમે aes ને બ્લેકમાં બદલો છો, તો પરિસ્થિતિ સંપૂર્ણપણે સુધરશે:

કાર્યકારી કલાકો:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

4m33 સે
4m43 સે
4m40 સે

59s
1m0 સે
1m0 સે

1m38 સે
1m43 સે
1m40 સે

ઝેડબેકઅપના કિસ્સામાં, રીપોઝીટરીનું કદ 13GB હતું અને તેનાથી થોડું ઓછું પણ, જે સામાન્ય રીતે અપેક્ષિત છે. હું ચાલી રહેલા સમયથી ખૂબ જ ખુશ હતો; તે librsync પર આધારિત ઉકેલો સાથે તુલનાત્મક છે, જે ઘણી વ્યાપક ક્ષમતાઓ પ્રદાન કરે છે. હું પર્યાવરણ વેરીએબલ દ્વારા વિવિધ પરિમાણો સેટ કરવાની ક્ષમતાથી પણ ખુશ હતો, જે ઓટોમેટિક મોડમાં બોર્ગબેકઅપનો ઉપયોગ કરતી વખતે ખૂબ જ ગંભીર લાભ આપે છે. હું બેકઅપ દરમિયાન લોડથી પણ ખુશ હતો: પ્રોસેસર લોડ દ્વારા અભિપ્રાય આપતા, બોર્ગબેકઅપ 1 થ્રેડમાં કાર્ય કરે છે.

તેનો ઉપયોગ કરતી વખતે કોઈ ખાસ ગેરફાયદા ન હતી.

રેસ્ટિક પરીક્ષણ

એ હકીકત હોવા છતાં કે રેસ્ટિક એકદમ નવો ઉકેલ છે (પ્રથમ 2 ઉમેદવારો 2013 અને તેથી વધુ જૂનામાં જાણીતા હતા), તે ખૂબ સારી લાક્ષણિકતાઓ ધરાવે છે. ગોમાં લખેલું.

જ્યારે zbackup સાથે સરખામણી કરવામાં આવે છે, ત્યારે તે વધુમાં આપે છે:

• રીપોઝીટરીની અખંડિતતા તપાસવી (ભાગોમાં તપાસ સહિત).
• બેકઅપ્સ સ્ટોર કરવા માટે સપોર્ટેડ પ્રોટોકોલ્સ અને પ્રદાતાઓની વિશાળ યાદી, તેમજ ક્લાઉડ સોલ્યુશન્સ માટે rclone - rsync માટે સપોર્ટ.
• એકબીજા સાથે 2 બેકઅપની તુલના.
• ફ્યુઝ દ્વારા રીપોઝીટરી માઉન્ટ કરવાનું.

સામાન્ય રીતે, સુવિધાઓની સૂચિ બોર્ગબેકઅપની તદ્દન નજીક છે, કેટલીક જગ્યાએ વધુ, અન્યમાં ઓછી. એક વિશેષતા એ છે કે એન્ક્રિપ્શનને અક્ષમ કરવાની કોઈ રીત નથી, અને તેથી બેકઅપ નકલો હંમેશા એન્ક્રિપ્ટેડ રહેશે. ચાલો વ્યવહારમાં જોઈએ કે આ સૉફ્ટવેરમાંથી શું સ્ક્વિઝ કરી શકાય છે:

પરિણામો નીચે મુજબ હતા:

કાર્યકારી કલાકો:

1 લોન્ચ કરો
2 લોન્ચ કરો
3 લોન્ચ કરો

5m25 સે
5m50 સે
5m38 સે

35s
38s
36s

1m54 સે
2m2 સે
1m58 સે

કામગીરીના પરિણામો પણ rsync-આધારિત સોલ્યુશન્સ સાથે સરખાવી શકાય છે અને સામાન્ય રીતે, બોર્ગબેકઅપની ખૂબ નજીક છે, પરંતુ CPU લોડ વધારે છે (બહુવિધ થ્રેડો ચાલી રહ્યા છે) અને સૉટૂથ.

મોટે ભાગે, પ્રોગ્રામ ડેટા સ્ટોરેજ સર્વર પર ડિસ્ક સબસિસ્ટમના પ્રદર્શન દ્વારા મર્યાદિત છે, જેમ કે પહેલાથી જ rsync સાથે કેસ હતો. રિપોઝીટરીનું કદ 13GB હતું, જેમ કે zbackup અથવા borgbackup, આ સોલ્યુશનનો ઉપયોગ કરતી વખતે કોઈ સ્પષ્ટ ગેરફાયદા ન હતા.

રિઝલ્ટ

વાસ્તવમાં, બધા ઉમેદવારોએ સમાન પરિણામો હાંસલ કર્યા, પરંતુ અલગ-અલગ ભાવે. બોર્ગબેકઅપ એ સર્વશ્રેષ્ઠ પ્રદર્શન કર્યું, રેસ્ટિક થોડું ધીમું હતું, ઝેડબેકઅપ કદાચ ઉપયોગ કરવાનું શરૂ કરવા યોગ્ય નથી,
અને જો તે પહેલેથી ઉપયોગમાં છે, તો તેને બોર્ગબેકઅપ અથવા રેસ્ટિકમાં બદલવાનો પ્રયાસ કરો.

તારણો

સૌથી આશાસ્પદ ઉકેલ શાંત લાગે છે, કારણ કે... તે તે છે જેની પાસે ઓપરેટિંગ સ્પીડ માટે ક્ષમતાઓનો શ્રેષ્ઠ ગુણોત્તર છે, પરંતુ હવે માટે આપણે સામાન્ય નિષ્કર્ષ પર ઉતાવળ ન કરીએ.

Borgbackup મૂળભૂત રીતે કોઈ ખરાબ નથી, પરંતુ zbackup કદાચ વધુ સારી રીતે બદલાયેલ છે. સાચું, 3-2-1 નિયમ કામ કરે છે તેની ખાતરી કરવા માટે zbackup હજુ ​​પણ વાપરી શકાય છે. ઉદાહરણ તરીકે, (lib)rsync-આધારિત બેકઅપ સુવિધાઓ ઉપરાંત.

ઘોષણા

બેકઅપ, ભાગ 1: શા માટે બેકઅપની જરૂર છે, પદ્ધતિઓ, તકનીકોની ઝાંખી
બેકઅપ ભાગ 2: rsync-આધારિત બેકઅપ સાધનોની સમીક્ષા અને પરીક્ષણ
બેકઅપ ભાગ 3: ડુપ્લીસીટી, ડુપ્લીકેટીની સમીક્ષા અને પરીક્ષણ
બેકઅપ ભાગ 4: ઝેડબેકઅપ, રેસ્ટિક, બોર્ગબેકઅપની સમીક્ષા અને પરીક્ષણ
બેકઅપ ભાગ 5: લિનક્સ માટે બેક્યુલા અને વીમ બેકઅપનું પરીક્ષણ
બેકઅપ ભાગ 6: બેકઅપ સાધનોની સરખામણી
બેકઅપ ભાગ 7: તારણો

મોકલનાર: પાવેલ ડેમકોવિચ

સોર્સ: www.habr.com