کنٹینر کا بیک اپ یا اس کی فائلوں کا؟ بحالی کی شکل کے مطابق فیصلہ کریں
امیج اور فائل سطح کے بیک اپ مختلف چیزیں بحال کرتے ہیں اور مختلف چابیوں پر منحصر ہیں۔ محفوظ شدہ شے کو اسی بحالی سے ہم آہنگ کریں جس کی آپ کو واقعی ضرورت ہے۔
آپ کسی خفیہ کردہ کنٹینر کا بیک اپ ایک ہی شے کے طور پر لے سکتے ہیں، یا اسے ماؤنٹ کر کے اندر کی فائلوں کا بیک اپ لے سکتے ہیں۔ دونوں VPN سے آسانی سے گزرتے ہیں، اور مشابہت وہیں ختم ہو جاتی ہے۔ وہ مختلف چیزیں بحال کرتے ہیں، مختلف چابیوں پر منحصر ہیں، مختلف جگہ لیتے ہیں، اور جب کسی کو ڈیٹا واپس چاہیے ہو تو مختلف طریقوں سے ناکام ہوتے ہیں۔ پہلے بحالی کی شے منتخب کریں، پھر ترسیل، پھر محفوظ نقل کی خفیہ کاری۔ نیچے دی گئی فہرست اسی ترتیب سے چلتی ہے، کیونکہ تقریباً ہر بیک اپ تنازعہ دراصل اس پر اختلاف ہے کہ ان تینوں میں سے کون سا فیصلہ پہلے ہوا۔
دو اشیاء، بحالی کی دو شکلیں
امیج سطح کا بیک اپ کنٹینر بحال کرتا ہے: خفیہ کردہ حجم واپس ملتا ہے اور اسے کھولنے کے لیے اب بھی اس کا بحالی مواد درکار ہے۔ فائل سطح کا بیک اپ فائلیں اور ڈائریکٹری درخت بحال کرتا ہے، اور ان کی حفاظت کرنے والی کوئی بھی خفیہ کاری بیک اپ مخزن کی خصوصیت ہے، اصل کنٹینر کی نہیں۔ دور کے فولڈر میں سادہ نقل تیسرا معاملہ ہے، اور اسے وہی تحفظ ورثے میں ملتا ہے جو اس فولڈر کے پاس اتفاقاً موجود ہو۔
| Object | What a restore gives you | Where the encryption question lands |
|---|---|---|
| Encrypted container image | The volume, still locked | The container format and its recovery key material |
| Mounted files into a backup tool | Selected files and metadata | The backup repositorys own keys and design |
| Plain copy to a remote folder | Whatever the copy process kept | Whatever protects that storage afterwards |
درمیانی سطر وہی ہے جسے لوگ غلط پڑھتے ہیں۔ یہ بالکل اچھا ڈیزائن ہو سکتا ہے: بیک اپ پروگرام مقامی طور پر صاف متن پڑھتا ہے اور خفیہ کردہ، تصدیق شدہ مخزن لکھتا ہے۔ تب حفاظت اسی پروگرام اور اس کی اسناد پر ٹکتی ہے، اصل کنٹینر کے پاس ورڈ پر نہیں، اور دونوں کو ایک ہی کنٹرول کے طور پر بیان نہیں کرنا چاہیے۔
جانچ 1: بحالی کو کیا دوبارہ تعمیر کرنا ہے؟
سوال بیک اپ کے بجائے بحالی کی شکل میں پوچھیں۔ اگر ضرورت یہ ہے کہ ”اس سروس کو کسی دوسرے ہوسٹ پر واپس لائیں“، تو امیج اور اس کا بحالی مواد مربوط جواب ہے۔ اگر ضرورت یہ ہے کہ ”مارچ کی مالی اسپریڈ شیٹ واپس لائیں“، تو ایک فائل نکالنے کے لیے کئی گیگابائٹ کی امیج بحال کرنا مہنگا جواب ہے۔ دونوں جائز بحالیاں ہیں، اور یہ ایک دوسرے کی جگہ لینے والے بجٹ نہیں۔ صرف ایک کا نام لینے والا منصوبہ آخرکار دوسرے سے جانچا جائے گا۔
بحالی کا ہدف منصوبے میں لکھیں: پورا حجم، ڈائریکٹری درخت، یا الگ الگ فائلیں۔ پھر نوٹ کریں کہ کون سا میٹاڈیٹا ان کے ساتھ سفر کرنا چاہیے، کیونکہ ملکیت، اجازتیں، توسیع شدہ خصوصیات اور وقت کے نشانات فائل سطح کی بحالی کا حصہ ہیں اور جانچ کے دوران کافی دکھنے والے نقل پر مبنی کام کے بہاؤ میں وہ اکثر ضائع ہو جاتے ہیں۔
یہ بھی طے کریں کہ بحالی کون کرتا ہے۔ فائل سطح کا مخزن جسے کوئی بھی آپریٹر ماؤنٹ کر سکتا ہے، اس امیج سے مختلف رسائی ماڈل ہے جس کے لیے چابی رکھنے والے کی موجودگی ضروری ہے، اور کوئی بھی خودبخود بہتر نہیں۔ اہم یہ ہے کہ انتخاب دانستہ اور تحریری ہو۔
جانچ 2: محفوظ نقل کی حفاظت کیا کرتا ہے؟
VPN ترسیل کے ایک حصے کی حفاظت کرتا ہے۔ منتقلی کے ختم ہونے کے بعد محفوظ نقل کے بارے میں یہ کچھ نہیں کہتا، اور ”یہ سرنگ سے گزرا“ بیک اپ آپریٹر کی آپ کا ڈیٹا پڑھنے کی صلاحیت کے بارے میں بیان نہیں ہے۔ اگر دور کا فریق کوئی اور چلا رہا ہے، تو سوال یہ ہے کہ وہ کیا پڑھ سکتے ہیں، یہ نہیں کہ رابطہ خفیہ تھا یا نہیں۔
امیج کے لیے اس کا مطلب ہے کنٹینر کے چابی مواد کو خود امیج سے الگ محفوظ کرنا۔ ہیڈر کھونا حجم کھونا ہے، اس لیے ہیڈر کا بیک اپ وہاں لیں جہاں امیج نہیں ہے:
cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20فائل سطح کے مخزن کے لیے، جانچیں کہ اوزار ہوسٹ چھوڑنے سے پہلے مواد اور میٹاڈیٹا کو خفیہ اور تصدیق شدہ کرتا ہے، اور جانیں کہ چابیاں کس کے پاس ہیں۔ Restic کی ڈیزائن دستاویزات واضح طور پر کہتی ہیں کہ یہ قابل اعتماد ماخذ ہوسٹ فرض کرتی ہیں اور خفیہ کاری ان لوگوں کو بیک اپ حذف کرنے سے نہیں روکتی جن کے پاس ذخیرے تک رسائی ہے۔ دونوں انتباہ اہم ہیں: مخزن راز ہو سکتا ہے اور پھر بھی تباہ ہو سکتا ہے۔
جانچ 3: کیا نقل مستقل ہے؟
جو بیک اپ بدلتے ہوئے فائل سسٹم کو ریکارڈ کرتا ہے وہ نقل ہے، بحالی نقطہ نہیں۔ امیج کے لیے والیوم اوزار کی معاون طریقہ سے مستحکم اسنیپ شاٹ لیں، جس کا عام مطلب اسنیپ شاٹ عمل یا آن ماؤنٹ ہے، بڑی فائل کے بدلتے رہتے اسے پڑھنا نہیں:
lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonlyماؤنٹ شدہ فائلوں کے لیے فعال ڈیٹا بیس اور دیگر مربوط ڈیٹا کے لیے ایپلیکیشن کی معاون مستقل مزاجی طریقہ کار استعمال کریں۔ فائل سسٹم سطح کی نقل اور ایپلیکیشن سے ہم آہنگ بحالی نقطہ مختلف وضاحتیں ہیں، اور فرق صرف اس وقت نظر آتا ہے جب آپ بحال شدہ نقل سے ایپلیکیشن شروع کرنے کی کوشش کرتے ہیں۔
بحالی مواد کو آزاد محفوظ راستے پر رکھیں۔ اصل مشین کھونے کا مطلب کبھی یہ نہیں ہونا چاہیے کہ اس کے بیک اپ کو کھولنے والا واحد سند بھی کھو جائے، اور یہی اس وقت ہوتا ہے جب چابی کی فائل اسی حجم پر رہتی ہے جس کا بیک اپ لیا جا رہا ہے۔ اس علیحدگی کو دانستہ جانچیں: ایسے ہوسٹ پر بحالی کریں جس نے اصل کو کبھی نہیں دیکھا، صرف وہی استعمال کرتے ہوئے جو منصوبہ کہتا ہے دستیاب ہے۔
جانچ 4: کیا اس شے کے لیے تبدیلی کی شناخت لاگو ہوتی ہے؟
خفیہ کردہ کنٹینر زیادہ تر ترسیل اوزاروں کو ایک بڑی مبہم فائل لگتا ہے، اس لیے صاف متن میں چھوٹی ترمیم اوزار اور فارمیٹ کے مطابق بڑی دوبارہ پڑھائی یا مکمل دوبارہ اپ لوڈ کا سبب بن سکتی ہے۔ restic کے مطابق متغیر حجم کی تقسیم اور نقل کا خاتمہ اسے کم کر سکتے ہیں، لیکن یہ اس اوزار کی خصوصیت ہے، عام طور پر خفیہ کردہ کنٹینروں کی نہیں۔
فرض کرنے کے بجائے پیمائیں۔ چھوٹی، بے ضرر تبدیلی کے بعد پہلی دوڑ کا دوسری سے موازنہ کریں، اور منتقل شدہ بائٹ اور گزرا وقت دونوں درج کریں۔ تجربے کے دوران معلوم-اچھا بیک اپ رکھیں، تاکہ کوئی جانچ آپ کا واحد بحالی نقطہ خرچ نہ کر دے۔
پھر فہرست کو اس واحد اہم جانچ سے مکمل کریں: اصل مشین کے بغیر بحالی۔ بحال شدہ کنٹینر کھولیں، یا منتخب فائلیں ان کے میٹاڈیٹا کے ساتھ بحال کریں، اور یقینی بنائیں کہ ایپلیکیشن یا صارف نتیجہ استعمال کر سکتا ہے۔ وہ تیز، اچھی طرح خفیہ کردہ ترسیل جو اس جانچ کا جواب نہیں دے سکتی، آپ کے ڈیٹا کی نقل ہے، اس کا بیک اپ نہیں۔