بيڪ اپ حصو 7: نتيجو

بيڪ اپ حصو 7: نتيجو

هي نوٽ بيڪ اپ بابت چڪر مڪمل ڪري ٿو. اهو هڪ وقف سرور (يا VPS) جي منطقي تنظيم تي بحث ڪندو، بيڪ اپ لاءِ آسان، ۽ هڪ آپشن پڻ پيش ڪندو سرور کي جلدي بحال ڪرڻ لاءِ بيڪ اپ کان بغير ڪنهن آفت جي صورت ۾ گهڻو وقت بند ڪرڻ جي.

شروعاتي ڊيٽا

هڪ وقف ٿيل سرور اڪثر ڪري گهٽ ۾ گهٽ ٻه هارڊ ڊرائيو آهن جيڪي پهرين سطح جي RAID صف کي منظم ڪرڻ جي خدمت ڪن ٿا (عڪس). اهو ضروري آهي ته سرور کي هلائڻ جاري رکڻ جي قابل هجي جيڪڏهن هڪ ڊسڪ ناڪام ٿئي. جيڪڏهن اهو هڪ باقاعده وقف سرور آهي، اتي ٿي سگهي ٿو هڪ الڳ هارڊويئر RAID ڪنٽرولر SSD تي فعال ڪيشنگ ٽيڪنالاجي سان، ته جيئن باقاعده هارڊ ڊرائيو کان علاوه، هڪ يا وڌيڪ SSDs ڳنڍي سگهجن. ڪڏهن ڪڏهن وقف سرور پيش ڪيا ويندا آهن، جن ۾ صرف مقامي ڊسڪ SATADOM (ننڍيون ڊسڪون، ساخت جي طور تي هڪ فليش ڊرائيو SATA بندرگاهه سان ڳنڍيل آهن)، يا اڃا به هڪ عام ننڍي (8-16GB) فليش ڊرائيو هڪ خاص اندروني بندرگاهه سان ڳنڍيل آهي، ۽ ڊيٽا اسٽوريج سسٽم مان ورتو وڃي ٿو، هڪ وقف ٿيل اسٽوريج نيٽ ورڪ ذريعي ڳنڍيل آهي (ايٿرنيٽ 10G، ايف سي، وغيره)، ۽ اتي وقف سرور آهن جيڪي سڌو سنئون اسٽوريج سسٽم مان لوڊ ڪيا ويا آهن. مان اهڙن اختيارن تي غور نه ڪندس، ڇو ته اهڙين حالتن ۾ سرور کي بيڪ اپ ڪرڻ جو ڪم آسانيء سان ماهر ڏانهن گذري ٿو جيڪو اسٽوريج سسٽم کي برقرار رکندو آهي؛ عام طور تي سنيپ شاٽ ٺاهڻ، بلٽ ان ڊيڊپليڪيشن ۽ سسٽم ايڊمنسٽريٽر جي ٻين خوشين لاءِ مختلف ملڪيت وارا ٽيڪنالاجيون آهن. هن سلسلي جي پوئين حصن ۾ بحث ڪيو ويو آهي. سرور سان ڳنڍيل ڊسڪ جي تعداد ۽ سائيز تي منحصر ڪري، هڪ وقف سرور جي ڊسڪ صف جو حجم ڪيترن ئي ڏهن ٽيرا بائيٽ تائين پهچي سگھي ٿو. VPS جي صورت ۾، حجم وڌيڪ معمولي آهن: عام طور تي 100GB کان وڌيڪ نه آهن (پر اتي پڻ وڌيڪ آهن)، ۽ اهڙي وي پي ايس لاء ٽريف آساني سان سستي سرشار سرورز کان وڌيڪ قيمتي ٿي سگهي ٿو ساڳئي ميزبان کان. هڪ وي پي ايس اڪثر ڪري هڪ ڊسڪ هوندي آهي، ڇاڪاڻ ته ان جي هيٺان هڪ اسٽوريج سسٽم (يا ڪجهه هائپر ڪنورجڊ) هوندو. ڪڏهن ڪڏهن هڪ VPS وٽ ڪيترائي ڊسڪ آهن مختلف خاصيتن سان، مختلف مقصدن لاءِ:

  • ننڍو سسٽم - آپريٽنگ سسٽم کي نصب ڪرڻ لاء؛
  • وڏي-اسٽورنگ صارف ڊيٽا.

جڏهن توهان ڪنٽرول پينل استعمال ڪندي سسٽم کي ٻيهر نصب ڪيو، صارف جي ڊيٽا سان ڊسڪ اوور رائٽ نه آهي، پر سسٽم ڊسڪ مڪمل طور تي ڀريل آهي. انهي سان گڏ، هڪ VPS جي صورت ۾، ميزبان هڪ بٽڻ پيش ڪري سگهي ٿو جيڪو VPS (يا ڊسڪ) جي حالت جو هڪ سنيپ شاٽ وٺي ٿو، پر جيڪڏهن توهان پنهنجو آپريٽنگ سسٽم نصب ڪيو يا VPS اندر گهربل خدمت کي چالو ڪرڻ وساريو، ڪجهه ڊيٽا جي اڃا به گم ٿي سگهي ٿو. بٽڻ کان علاوه، هڪ ڊيٽا اسٽوريج سروس عام طور تي پيش ڪيو ويندو آهي، اڪثر گهڻو ڪري تمام محدود. عام طور تي هي هڪ اڪائونٽ آهي جنهن ۾ FTP يا SFTP ذريعي رسائي هوندي آهي، ڪڏهن ڪڏهن SSH سان گڏ، هڪ سٽيل-ڊائون شيل سان (مثال طور، rbash)، يا authorized_keys ذريعي حڪم هلائڻ تي پابندي (ForcedCommand ذريعي).

هڪ وقف سرور نيٽ ورڪ سان ڳنڍيل آهي ٻه بندرگاهن جي رفتار سان 1 Gbps، ڪڏهن ڪڏهن اهي ڪارڊ ٿي سگهن ٿا 10 Gbps جي رفتار سان. VPS اڪثر ڪري هڪ نيٽ ورڪ انٽرفيس آهي. گهڻو ڪري، ڊيٽا مرڪز ڊيٽا سينٽر اندر نيٽ ورڪ جي رفتار کي محدود نه ڪندا آهن، پر اهي انٽرنيٽ جي رسائي جي رفتار کي محدود ڪن ٿا.

اهڙي سرشار سرور يا VPS جو عام لوڊ هڪ ويب سرور، هڪ ڊيٽابيس، ۽ هڪ ايپليڪيشن سرور آهي. ڪڏهن ڪڏهن مختلف اضافي معاون خدمتون انسٽال ٿي سگھن ٿيون، بشمول ويب سرور يا ڊيٽابيس لاءِ: سرچ انجڻ، ميل سسٽم وغيره.

هڪ خاص طور تي تيار ڪيل سرور بيڪ اپ ڪاپيون محفوظ ڪرڻ لاءِ جاءِ جي طور تي ڪم ڪري ٿو؛ اسان ان بابت وڌيڪ تفصيل سان بعد ۾ لکنداسين.

ڊسڪ سسٽم جي منطقي تنظيم

جيڪڏهن توهان وٽ هڪ RAID ڪنٽرولر آهي، يا هڪ ڊسڪ سان هڪ VPS، ۽ ڊسڪ سبسسٽم جي آپريشن لاء ڪا خاص ترجيحات نه آهي (مثال طور، ڊيٽابيس لاء هڪ الڳ فاسٽ ڊسڪ)، سڀ مفت جاء هن ريت ورهايل آهي: هڪ ورهاڱي ٺاھيو ويو آھي، ۽ ھڪڙو LVM حجم گروپ ٺاھيو ويو آھي ان جي مٿان، ان ۾ ڪيترائي حجم ٺاھيا ويا آھن: 2 ساڳيا سائيز جا ننڍا، روٽ فائل سسٽم جي طور تي استعمال ڪيا ويا آھن (تڪڙو رول بيڪ جي امڪان لاء تازه ڪاري دوران ھڪڙي ھڪڙي تبديل ڪئي وئي، اهو خيال ڪيڪليٽ لينڪس ڊسٽري بيوشن مان ورتو ويو آهي)، ٻيو هڪ ادل بدلي ورهاڱي لاءِ آهي، باقي خالي جاءِ ننڍي مقدار ۾ ورهايل آهي، مڪمل ڪنٽينرز لاءِ روٽ فائيل سسٽم طور استعمال ڪيو ويندو آهي، ورچوئل مشينن لاءِ ڊسڪ، فائل /home ۾ اڪائونٽس لاءِ سسٽم (هر کاتي جو پنهنجو فائيل سسٽم هوندو آهي)، ايپليڪيشن ڪنٽينرز لاءِ فائل سسٽم.

اھم نوٽ: حجم مڪمل طور تي پاڻ ۾ شامل ھجن، يعني. هڪ ٻئي تي يا روٽ فائل سسٽم تي انحصار نه ڪرڻ گهرجي. مجازي مشينن يا ڪنٽينرز جي صورت ۾، هي نقطو خودڪار طريقي سان ڏٺو ويندو آهي. جيڪڏهن اهي ايپليڪيشن ڪنٽينر يا گهر ڊاريڪٽريون آهن، توهان کي سوچڻ گهرجي ته ويب سرور ۽ ٻين خدمتن جي ڪنفيگريشن فائلن کي الڳ ڪرڻ لاءِ اهڙي طرح جيئن جيترو ممڪن ٿي سگهي حجم جي وچ ۾ انحصار کي ختم ڪيو وڃي. مثال طور، هر سائيٽ پنهنجي استعمال ڪندڙ کان هلندي آهي، سائيٽ جي ترتيب واري فائلون صارف جي گهر ڊاريڪٽري ۾ آهن، ويب سرور سيٽنگن ۾، سائيٽ جي ترتيب واري فائلون شامل نه آهن /etc/nginx/conf.d/ ذريعي..conf، ۽، مثال طور، /home//configs/nginx/*.conf

جيڪڏهن اتي ڪيتريون ئي ڊسڪون آهن، توهان هڪ سافٽ ويئر RAID سري ٺاهي سگهو ٿا (۽ ان جي ڪيشنگ کي SSD تي ترتيب ڏيو، جيڪڏهن ضرورت ۽ موقعو هجي)، جنهن جي مٿان توهان مٿي ڏنل تجويز ڪيل قاعدن مطابق LVM ٺاهي سگهو ٿا. انهي صورت ۾، توهان ZFS يا BtrFS استعمال ڪري سگهو ٿا، پر توهان کي هن بابت ٻه ڀيرا سوچڻ گهرجي: ٻنهي وسيلن جي وڌيڪ سنجيده طريقي جي ضرورت آهي، ۽ ان کان علاوه، ZFS لينڪس ڪنيل سان شامل نه آهي.

استعمال ٿيل اسڪيم جي باوجود، اهو هميشه اڳ ۾ اندازو لڳائڻ جي قابل آهي ڊسڪ ۾ تبديلين جي لکڻ جي اندازي جي رفتار، ۽ پوء خالي جاء جي مقدار کي ڳڻڻ جيڪا سنيپ شاٽ ٺاهڻ لاء محفوظ ڪئي ويندي. مثال طور، جيڪڏهن اسان جو سرور 10 ميگا بائيٽ في سيڪنڊ جي رفتار سان ڊيٽا لکي ٿو، ۽ سڄي ڊيٽا جي صف جي سائيز 10 ٽيرا بائيٽ آهي - هم وقت سازي جو وقت هڪ ڏينهن تائين پهچي سگهي ٿو (22 ڪلاڪ - اهو آهي ڪيترو حجم منتقل ڪيو ويندو. نيٽ ورڪ تي 1 Gbps) - اهو 800 GB بابت محفوظ ڪرڻ جي قابل آهي. حقيقت ۾، انگن اکرن ننڍو ٿيندو؛ توهان محفوظ طور تي ان کي منطقي مقدار جي تعداد سان ورهائي سگهو ٿا.

بيڪ اپ اسٽوريج سرور ڊوائيس

بيڪ اپ نقلن کي محفوظ ڪرڻ لاءِ سرور جي وچ ۾ بنيادي فرق ان جي وڏي، سستي ۽ نسبتاً سست ڊسڪ آهي. جيئن ته جديد HDDs اڳ ۾ ئي هڪ ڊسڪ ۾ 10TB بار کي پار ڪري چڪو آهي، اهو ضروري آهي ته فائل سسٽم يا RAID کي چيڪسم سان استعمال ڪيو وڃي، ڇاڪاڻ ته سرن جي ٻيهر تعمير يا فائل سسٽم جي بحالي دوران (ڪيترائي ڏينهن!) ٻي ڊسڪ ناڪام ٿي سگهي ٿي. لوڊ وڌائڻ لاء. 1TB تائين جي گنجائش سان ڊسڪ تي اهو ايترو حساس نه هو. وضاحت جي سادگي لاءِ، مان سمجهان ٿو ته ڊسڪ اسپيس کي ٻن حصن ۾ ورهايو ويو آهي تقريبن برابر سائيز جي (ٻيهر، مثال طور، LVM استعمال ڪندي):

  • استعمال ڪندڙ ڊيٽا کي ذخيرو ڪرڻ لاء استعمال ڪيل سرورز سان لاڳاپيل حجم (آخري بيڪ اپ انهن تي تصديق لاء مقرر ڪيو ويندو)؛
  • حجم BorgBackup repositories طور استعمال ڪيو ويو (بيڪ اپ لاء ڊيٽا سڌو هتي ويندا).

آپريشن جو اصول اهو آهي ته BorgBackup مخزن لاءِ هر سرور لاءِ الڳ حجم ٺاهيا ويا آهن، جتي جنگي سرورن مان ڊيٽا ويندي. ريپوزٽريز صرف اپينڊ موڊ ۾ ڪم ڪن ٿيون، جيڪي ڊيٽا کي ارادي طور تي ڊليٽ ڪرڻ جي امڪان کي ختم ڪري ٿي، ۽ پراڻي بيڪ اپ مان ريپوزٽريز جي نقل ۽ وقتي صفائي جي ڪري (سالياني ڪاپيون رهنديون آهن، گذريل سال لاءِ مهيني، گذريل مهيني لاءِ هفتيوار، روزاني لاءِ. گذريل هفتي، ممڪن طور تي خاص ڪيسن ۾ - آخري ڏينهن لاءِ ڪلاڪ: ڪل 24 + 7 + 4 + 12 + سالياني - تقريبن 50 ڪاپيون هر سرور لاءِ).
BorgBackup repositories صرف ضميمه موڊ کي فعال نه ڪندا آهن؛ ان جي بدران، .ssh/authorized_keys ۾ هڪ ForcedCommand استعمال ڪيو ويندو آهي ڪجهه هن طرح:

from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......

بيان ڪيل رستي ۾ بورگ جي چوٽي تي هڪ لفافي اسڪرپٽ شامل آهي، جيڪو بائنري کي پيرا ميٽرز سان شروع ڪرڻ کان علاوه، ڊيٽا کي هٽائڻ کان پوء بيڪ اپ ڪاپي کي بحال ڪرڻ جي عمل کي شروع ڪري ٿو. هن کي ڪرڻ لاء، لفافي اسڪرپٽ ٺاهي ٿو هڪ ٽيگ فائل لاڳاپيل مخزن جي اڳيان. آخري بيڪ اپ ٺاهيو ويو آهي خودڪار طريقي سان لاڳاپيل منطقي حجم تي بحال ٿيڻ کانپوءِ ڊيٽا ڀرڻ وارو عمل مڪمل ٿيڻ کان پوءِ.

هي ڊيزائن توهان کي وقتي طور تي غير ضروري بيڪ اپ کي صاف ڪرڻ جي اجازت ڏئي ٿو، ۽ جنگي سرور کي به روڪي ٿو بيڪ اپ اسٽوريج سرور تي ڪنهن به شيءِ کي حذف ڪرڻ کان.

بيڪ اپ عمل

بيڪ اپ جي شروعات ڪندڙ سرشار سرور يا VPS پاڻ آهي، ڇاڪاڻ ته هي اسڪيم هن سرور جي حصي تي بيڪ اپ جي عمل تي وڌيڪ ڪنٽرول ڏئي ٿو. پهريون، فعال روٽ فائل سسٽم جي حالت جو هڪ سنيپ شاٽ ورتو ويو آهي، جيڪو نصب ڪيو ويو آهي ۽ اپ لوڊ ڪيو ويو آهي BorgBackup استعمال ڪندي بيڪ اپ اسٽوريج سرور تي. ڊيٽا کي پڪڙڻ کان پوء مڪمل ٿيڻ کان پوء، سنيپ شاٽ کي غير نصب ڪيو ويو ۽ ختم ڪيو ويو.

جيڪڏهن هڪ ننڍڙو ڊيٽابيس آهي (هر سائيٽ لاءِ 1 GB تائين)، هڪ ڊيٽابيس ڊمپ ٺاهيو ويندو آهي، جيڪو مناسب منطقي حجم ۾ محفوظ ڪيو ويندو آهي، جتي ساڳئي سائيٽ لاءِ باقي ڊيٽا موجود هوندي آهي، پر انهي ڪري ته ڊمپ آهي. ويب سرور ذريعي دستياب ناهي. جيڪڏهن ڊيٽابيس وڏا آهن، توهان کي ترتيب ڏيڻ گهرجي "گرم" ڊيٽا هٽائڻ، مثال طور، MySQL لاءِ xtrabackup استعمال ڪندي، يا WAL سان ڪم ڪريو archive_command سان PostgreSQL ۾. انهي حالت ۾، ڊيٽابيس کي بحال ڪيو ويندو الڳ الڳ سائيٽ جي ڊيٽا کان.

جيڪڏهن ڪنٽينر يا ورچوئل مشينون استعمال ڪيون وڃن، توهان کي qemu-مهمان-ايجنٽ، CRIU يا ٻيون ضروري ٽيڪنالاجيون ترتيب ڏيڻ گهرجن. ٻين حالتن ۾، اضافي سيٽنگون اڪثر ڪري گهربل نه هونديون آهن - اسان صرف منطقي حجم جا سنيپ شاٽ ٺاهيندا آهيون، جيڪي پوء ساڳئي طريقي سان پروسيس ڪيا ويندا آهن جيئن روٽ فائل سسٽم جي حالت جي سنيپ شاٽ. ڊيٽا وٺڻ کان پوء، تصويرون ختم ٿي وينديون آهن.

وڌيڪ ڪم بيڪ اپ اسٽوريج سرور تي ڪيو ويندو آهي:

  • هر مخزن ۾ ٺهيل آخري بيڪ اپ چيڪ ڪيو ويو آهي،
  • ھڪڙي نشان واري فائل جي موجودگي کي چڪاس ڪيو ويو آھي، اشارو ڪري ٿو ته ڊيٽا گڏ ڪرڻ جو عمل مڪمل ٿي چڪو آھي،
  • ڊيٽا کي وڌايو ويو آهي لاڳاپيل مقامي حجم تائين،
  • ٽيگ فائل ختم ٿي وئي آهي

سرور جي بحالي جي عمل

جيڪڏهن مکيه سرور مري وڃي ٿو، ته پوء هڪ ساڳيو وقف سرور شروع ڪيو ويو آهي، جيڪو ڪجهه معياري تصوير مان بوٽ ڪري ٿو. گهڻو ڪري ڊائون لوڊ نيٽ ورڪ تي ٿي ويندي، پر سرور کي ترتيب ڏيڻ واري ڊيٽا سينٽر ٽيڪنيشين کي فوري طور تي هن معياري تصوير کي ڊسڪ مان هڪ کي نقل ڪري سگهي ٿو. ڊائون لوڊ رام ۾ ٿئي ٿي، جنهن کان پوء وصولي جو عمل شروع ٿئي ٿو:

  • هڪ گذارش ڪئي وئي آهي بلاڪ ڊيوائس کي iscsinbd ذريعي يا ٻيو ساڳيو پروٽوڪول هڪ منطقي حجم سان ڳنڍڻ لاءِ جنهن ۾ فوت ٿيل سرور جي روٽ فائل سسٽم تي مشتمل هجي؛ جيئن ته روٽ فائيل سسٽم ننڍڙو هجڻ گهرجي، اهو قدم ڪجهه منٽن ۾ مڪمل ڪيو وڃي. بوٽ لوڊر پڻ بحال ٿيو؛
  • مقامي منطقي حجم جي جوڙجڪ کي ٻيهر بڻايو ويو آهي، منطقي حجم بيڪ اپ سرور مان dm_clone kernel module استعمال ڪندي ڳنڍيا ويندا آهن: ڊيٽا جي وصولي شروع ٿيندي، ۽ تبديليون فوري طور تي مقامي ڊسڪ ۾ لکيون وينديون آهن.
  • هڪ ڪنٽينر سڀني موجود جسماني ڊسڪ سان شروع ڪيو ويو آهي - سرور جي ڪارڪردگي مڪمل طور تي بحال ڪئي وئي آهي، پر گهٽ ڪارڪردگي سان؛
  • ڊيٽا جي هم وقت سازي مڪمل ٿيڻ کان پوء، بيڪ اپ سرور مان منطقي حجم ختم ٿي ويا آهن، ڪنٽينر کي بند ڪيو ويو آهي، ۽ سرور کي ريبوٽ ڪيو ويو آهي؛

ريبوٽ کان پوءِ، سرور وٽ سڀ ڊيٽا هوندي جيڪا اتي موجود هئي جڏهن ته بيڪ اپ ٺاهي وئي هئي، ۽ ان ۾ شامل هوندي به اهي سڀئي تبديليون جيڪي بحاليءَ جي عمل دوران ڪيون ويون هيون.

سيريز ۾ ٻيا مضمون

بيڪ اپ، حصو 1: ڇو بيڪ اپ جي ضرورت آهي، طريقن جو هڪ جائزو، ٽيڪنالاجيون
بيڪ اپ حصو 2: جائزو وٺڻ ۽ جانچڻ rsync جي بنياد تي بيڪ اپ اوزار
بيڪ اپ حصو 3: نقل جو جائزو ۽ جانچ، نقل
بيڪ اپ حصو 4: جائزو وٺڻ ۽ جانچڻ zbackup, restic, borgbackup
بيڪ اپ حصو 5: ٽيسٽنگ Bacula ۽ Veeam Backup for Linux
بيڪ اپ: حصو پڙهندڙن جي درخواست تي: AMANDA، UrBackup، BackupPC جو جائزو
بيڪ اپ حصو 6: بيڪ اپ اوزار جي مقابلي ۾
بيڪ اپ حصو 7: نتيجو

مان توهان کي دعوت ڏيان ٿو تجويز ڪيل اختيار تي بحث ڪرڻ لاءِ تبصرن ۾، توهان جي توجه جي مهرباني!

جو ذريعو: www.habr.com

تبصرو شامل ڪريو