انجمن‌های فارسی اوبونتو
کمک و پشتیبانی => انجمن عمومی => نویسنده: norouzi90 در 12 بهمن 1400، 10:33 ب‌ظ
-
با سلام،
با توجه به عکس پایینی و با استفاده از دستور dd :
۱-می خواهم از sda1 ، یک کلون کامل از فضای پارتیشن ( Used + Unused ) بگیرم ، دستور مربوطه چیست؟
۲- می خواهم از sda3 ، تنها از فضای استفاده شده ( Used ) کلون بگیرم ، دستور مربوطه چیست؟
۳- تنها از فضای استفاده شده ( Used ) برای کلون گیری ، در زمان برگرداندن سیستم به حالت قبل مشکلی ایجاد نمی کند و یا بهتر است و یا ضروری است که
از تمامی فضا ( Used + Unused ) ، کلون بگیریم؟
۴- اگر زمانی خواستم ، با استفاده از فایل ایمجی که در اختیار دارم ، سیستم را به حالت قبل برگردانم از چه دستوری بایستی استفاده نمایم؟
۵- این کارها(چه در مرحله ایمج گیری و چه استفاده از فایل های ایمج ، برای برگرداندن سیستم به حالت قبل) را بایستی در محیط لایو انجام بدهم؟
( راستش دراستفاده از آپشن های bs و count و conv و Sync و ... برای اینکار ماندم و در ضمن تنهابرای اینکه فضای used را برای sda3 در کلون گیری بدهم،
چیزی به ذهنم نرسید، این فضا را از کجا بدست بیاورم وچگونه به دستور بگویم تا تنها از فضای used کلون بگیرد و یا برای اینکار از این روش استفاده نمی کنند و مثلا یک آپشن خاصی بهش می دهند؟!)
-
۱- خیلی راحت با dd اینکار رو انجام بدید.
sudo dd if=/dev/sda1 of=sda1-backup.imgبه جای sda1-backup.img می‌تونید مسیر به جایی رو که می‌خواهید فایل ذخیره بشه، قرار بدید. فکر کنم بهتر باشه موقع اینکار، اون پارتیشن سوار نشده باشه. پس اگه سواره، unmount کنید.
sudo umount /dev/sda1
۲- بهتره برای اینکار، از fsarchiver یا clonezilla استفاده کنید. اگه می‌خواهید فقط فایلهای داخل اون فایل‌سیستم رو داشته باشید، می‌تونه یه tar ایجاد کنید.squashfs هم هست. این صفحه (https://wiki.archlinux.org/title/System_backup) از ویکی آرچ یه سری چیز‌ها رو توضیح داده.
به نظرم fsarchiver برای شما، سر راست‌ترین گزینه هست. این (https://forum.ubuntu-ir.org/index.php?topic=114207.0) یه راهنمایی برای fsarchiver هست.
۳- فکر نکنم مشکلی پیش بیاد. بسته به نحوه کلون کردن ممکنه uuid، label و اینجور چیز‌ها رو همره کلون نداشته باشید، ولی این نباید مشکل خاصی بوجود بیاره. احتمالا فقط لازم میشه تا فایل fstab رو تغییر بدید. شاید هم لازم باشه crypttab رو تغییر بدید، اگه از lucks برای رمزنگاری استفاده کرده باشید.
۴- بستگی به نحوه کلون کردن، محلی که کلون‌ها قرار دارند و شرایط سیستم داره. نمیشه همینجوری یه دستور داد.
۵- معمولا برای کلون کردن لازمه تا فایل‌سیستم مورد نظر رو یا به صورت فقط خواندنی سوار کنید یا اصلا نباید سوار باشه. اگه بخواهید فایل‌سیستم روت رو کلون کنید، احتمالا لازم میشه تا یکی از دو تا کار بالا رو انجام بدید، از اونجایی که unmount کردن فایل‌سیستم روت موقعی که سیستم بوت شده، ممکن نیست، برای این مورد لازم میشه تا از یه توزیع زنده استفاده کنید. برای بقیه فایل‌سیستم‌ها، اینکار الزامی نیست ولی استفاده از یه توزیع زنده، می‌تونه کار شما رو راحت‌تر کنه.
( راستش دراستفاده از آپشن های bs و count و conv و Sync و ... برای اینکار ماندم و در ضمن تنهابرای اینکه فضای used را برای sda3 در کلون گیری بدهم،
چیزی به ذهنم نرسید، این فضا را از کجا بدست بیاورم وچگونه به دستور بگویم تا تنها از فضای used کلون بگیرد و یا برای اینکار از این روش استفاده نمی کنند و مثلا یک آپشن خاصی بهش می دهند؟!)
فایل‌سیستم‌های لینوکس اینجور نیستند که همه اطلاعات رو پشت سر هم روی دیسک، ردیف کنند. مثلا اگه شما یه فایل‌سیستم ext4 داشته باشید به اندازه 80Gib که 20Gib اون پره، اینطور نیست که اون 20Gib همه پشت سر هم توی اول فایل‌سیستم ذخیره شده باشند، بلکه این 20Gib، توی سرتاسر فایل‌سیستم پخش شده. دلیل این اینه که سرعت دسترسی در اثر گذشت زمان، افت نکنه.
اگه همه اطلاعات پشت سر هم ذخیره بشن، وقتی که یه قسمتی پاک میشه، یه فضای خالی بین اطلاعات ایجاد میشه. این فضای خالی به تنهایی مشکلی نداره. اگه فایل‌سیستم موقع ذخیره اطلاعات جدید، اونها رو تکه تکه کنه و داخل این فضای‌های خای قرار بده، اینجوری میشه که بعد یه مدت مقدار قابل توجهی از اطلاعات مرتبط، پشت سر هم نیستند.
مثلا ممکنه یه فایل 2Gib، به چندین قسمت تقسیم شده باشه. موقعی که ما می‌خواهیم اون فایل رو بخونیم، فایل‌سیستم تکه اول رو از یه جا میاره، تکه دوم رو از یه جای دیگه و به همین ترتیب تا تکه آخر. از اونجایی که این اطلاعات روی حافظه، پشت سر هم قرار نگرفتند، مدت زمانی طول می‌کشه تا حافظه از یه جا بره سراغ جای بعدی. اینجوری تاخیر‌های کمی بین خوندن تکه‌های فایل ایحاد میشه و شما نتیجه رو توی کم شدن سرعت، می‌بینید.
سرعت خوندن اطلاعات پشت سر هم، معمولا از خوندن تصادفی اطلاعات سریع‌تره. چون توی مورد اول، از یه جا کار رو شروع می‌کنیم و ادامه می‌دیم تا به آخرش برسیم. توی مورد دوم، هر بار باید از یه جا شروع کرد، یه کمی دقت جبو و بعد جا رو عوض کرد، دوباره رفت جلو و به همین ترتیب تا زمانی که فایل کامل خونده بشه.
مشکل بالا، توی فایل‌سیستم ntfs پیش میاد که بعد از مدتی، تکه تکه میشه و سرعت میاد پایین. به خاطر همین باید هر چند وقت یه بار، روی درایور مورد نظر عملیات defragmentation رو انجام داد تا اطلاعات با نظم نوشته بشن و سرعت به حالت قبل برگرده.
توی فایل‌سیستم‌های لینوکسی، معمولا اصلا نیازی به اینکار نمیشه. چون اطلاعات با فاصله از هم نوشتن میشن و فضای خالی بین اونها وجود داره تا در آینده بشه فایل‌هایی با اندازه‌های متفاوت جای اونها گذاشت و مشکلی هم ایجاد نشه. البته اگه فایل‌سیستم تا اندازه زیادی پر شده باشه، این قابلیت دیگه به کار نمیاد چون فضای خالی کافی وجود نداره تا بشه اینکار رو کرد.
به غیر از چیز‌های بالا، حتی اگه اطلاعات پشت سر هم بوند، باز هم با اینکار کلون شما ناقص می‌بود. چون header فایل‌سیستم رو همراه کلون ذخیره می‌کردید ولی یه سری اطلاعات مربوط به خود فایل‌سیستم تا بدونه چحوری کار کنه، که توی سرتاسر فایل‌سیستم پخش شده هست رو از دست میدادید. نتیجه میشد یه کلون که ناقص بوده.
اگه کلا از فایل‌سیستم چیزی ذخیره نمی‌کردید، اونوقت یه سری اطلاعات پشت سر هم داشتید که نمی‌دونید باید باهاش چیکار کنید و چیزی هم نمی‌تونه به همین راحتی اونها رو بخونه. از اونجایی که اطلاعات مربوط به فایل‌سیستمِ حاملِ اونها، همراهشون نبوده، دستور mount یا بقیه ابزار‌ها هم نمی‌تونستند کار زیادی انجام بدند.
من خودم از zfs استفاده می‌کنم. چون توی خودش قابلیت snapshot داره. علاوه بر اینکه میشه این هر وقت نیاز شد، به این snapshot ها در حدود 20 ثانیه یا کمتر برگشت، میشه این snapshot ها رو در قالب فایل ذخیره کرد تا بعدا همه چیز رو از روی اون فایل برگردوند.
تازه خود فایل‌سیستم قابلیت فشرده‌سازی داره. یعنی بدون اینکه لازم باشه شما کار خاصی انجام بدید، هر اطلاعاتی که میگیره رو می‌تونه فشرده کنه تا جای کماری بگیرن. حتی داخل بدون نیاز به ابزار‌های خارجی، از رمزنگاری هم پشتیبانی می‌کته. در اصلی lvm + md + dm + یه فایل‌سیستم معمولی مثل xfs یا ext4 رو یه جا دارید.
md برای ایجاد raid هست و dm برای رمزنگاری توی کرنل لینوکس استفاده میشه. lucks از dm استفاده می‌کنه. lvm هم که احتمالا می‌دونید چی هست.
البته به خاطر مجوزش (cddl) نمی‌تونه همراه کرنل لینوکس منتشر بشه و به خاطر همین، استفاده از اون روی سیستم‌های لینوکسی، یکم بیشتر کار می‌بره.
btrfs می‌تونه یه جایگزین برای zfs باشه ولی هنوز بعضی از قابلیت‌های zfs رو نداره و بعضی قابلیت‌هاش، پایدار نیستند.
-
۱-
فایل‌سیستم‌های لینوکس اینجور نیستند که همه اطلاعات رو پشت سر هم روی دیسک، ردیف کنند.
چونکه در ext ، در نواحی مختلفی داده ها در پارتیشن نوشته می گردند ولی در NTFS (و احتمالا در FAT ) بصورت پشت سرهم داده ها درج می گردند،
بنظرم می شود در حالت NFTS ، با فرمان dd می شود کاری کرد که تنهااز داده های پارتیشن ، ایمیج گرفت و فضای خالی را در نظر نگیرد، البته بدین صورت:
در sda3 در سیستم من ، که پارتیشن ریشه است در صورتیکه از نوع فرمت NTFS استفاده می کردم ، الان اینقدر فضای داده های من است:
size: (140,760,791,442,993 bytes)
الان به آپشن bs ، مثلا مقدار bs=4096 را می دهم و بعد اگر 140,760,791,442,993 را تقسیم بر 4096 نماییم ، می شود حدودا 34365427600
همین مقدار 34365427600 ( برای اطمینان کمی بیشتر ) را به آپشن count می دهیم.
نظر شما در این مورد چیست؟
۲- دو واژه sync و rsync در علوم کامپیوتربه یک معنا و مفهوم هستند؟
و در ضمن وقتیکه به دستور dd ، آپشن sync را می دهیم ، تنها تغییرات را اعمال می کند؟
۳-
به غیر از چیز‌های بالا، حتی اگه اطلاعات پشت سر هم بوند، باز هم با اینکار کلون شما ناقص می‌بود. چون header فایل‌سیستم رو همراه کلون ذخیره می‌کردید ولی یه سری اطلاعات مربوط به خود فایل‌سیستم تا بدونه چحوری کار کنه، که توی سرتاسر فایل‌سیستم پخش شده هست رو از دست میدادید. نتیجه میشد یه کلون که ناقص بوده.
در مورد مفهوم header فایل‌سیستم چیزی متوجه نمی شوم ولی اگر مثلا یک کار خیلی ساده بخواهیم انجام بدهیم بدین صورت که:
با سی دی لایو ، بوسیله copy and paste ابتدا از پاریشن ریشه ( sda3 ) کپی بگیرم و بعد پارتیشن ریشه را فرمت کنم و بعد دوباره کپی فایلهای ریشه را که در جای دیگر است را دوباره بریزم در داخل همان پارتیشن ریشه که فرمت کرده ام ، آیا بنظرتان با این روش مشکلی پیش نماید و سیستم بوت می شود و درست کار می کند؟
۴-
من خودم از zfs استفاده می‌کنم. چون توی خودش قابلیت snapshot داره.
فکر می کنم در گنو/لینوکس بصورت پیش فرض از ext استفاده می کنند، بنظرتان اگر zfs دارای امکانات بهتری است ، چرا از آن استفاده نمی شود و بجای ext آنرا پیشنهاد نمی دهند؟
-
۱. در ntfs داده‌ها پشت هم نیستن. برای همین توش به defragment نیاز دارید. در ext خیلی بیشتر می‌تونید چنین انتظاری داشته باشید.
۲. نه. ارتباطی به هم ندارن. sync به معنای هم‌گام سازیه و rsyn c نام یک نرم‌افزاره. گزینهٔ sync در dd هم ارتباطی به این داستان نداره و در مورد حافظهٔ میانگیر رایانه است.
۳. به عوامل مختلفی بستگی داره. ولی در هر صورت به همین سادگی قابل انجام نیست.
۴. جون با لینوکس سازگار نیست. اگه دنبال سامانه پرونده‌ای با ویژگی‌های بهتر از ext4 هستید، btrfs انتخاب خوبیه.
-
۱-
در پارتیشن ریشه سیستم من در sda3 ،
۲۱ پوشه و ۴ فایل ، در اولین نگاه در پنجره اول فایل منیجر مربوط به این پارتیشن وجود دارد.
نام پوشه ها: var ، usr ، tmp ، sys ، srv ، sbin ، run ، root ، proc ، opt ، mnt ، media ، libx32 ، lib64 ، lib32 ، lib ، home ، etc ، dev ، boot ، bin
نام فایل ها : vmlinuz.old ، vmlinuz ، initrd.img.old ، initrd.img
چرا این پوشه ها خالی هستند؟ : srv ، opt ، libx32 ، lib32 ،
۲-
وقتیکه با نرم افزار timeshift ، از سیستم snapshot می گیرم ، علاوه بر پوشه های بالایی، این پوشه ها هم خالی هستند، چرا timeshift از فایل های درون این پوشه ها هم نسخه پشتیبان تهیه نمی کند، عبارتند از : tmp ، sys ، run ، proc ، mnt ، media ، dev
( بنظر خودم پوشه media برای mount سی دی رام بکار رفته و پوشه mnt برای mount پارتیشن ها و tmp هم برای قرارگیری فایل های موقت ،به این علت timeshift آنها را خالی نگه داشته، اگر این یکی ها را درست گفته باشم، پوشه های بعدی را نمی دانم.)
۳-
وقتیکه در محیط لایو از پارتیشن ریشه سیستم من در sda3 می خواهم ، copy and paste ، نمایم خطای عکس پایینی را می دهد.
هر چند که اکثریت فایل ها کپی می شوند ، ولی می خواستم علت این خطا را بدانم و همچنین می خواستم بدانم چه فایل هایی کپی نمی شوند؟
آیا این فایل هایی که از این طریق کپی نمی شوند در فرایند پشتیبان گیری و زمانیکه سیستم را بخواهیم restore نمایم مهمند و بایستی باشند؟
در محیط لایو و در خط فرمان با چه دستوری سیستم را می توانم ملزم به کپی گیری از آنها را نیز نمایم؟
-
۱-
چونکه در ext ، در نواحی مختلفی داده ها در پارتیشن نوشته می گردند ولی در NTFS (و احتمالا در FAT ) بصورت پشت سرهم داده ها درج می گردند،
بنظرم می شود در حالت NFTS ، با فرمان dd می شود کاری کرد که تنهااز داده های پارتیشن ، ایمیج گرفت و فضای خالی را در نظر نگیرد، البته بدین صورت:
در sda3 در سیستم من ، که پارتیشن ریشه است در صورتیکه از نوع فرمت NTFS استفاده می کردم ، الان اینقدر فضای داده های من است:
size: (140,760,791,442,993 bytes)
الان به آپشن bs ، مثلا مقدار bs=4096 را می دهم و بعد اگر 140,760,791,442,993 را تقسیم بر 4096 نماییم ، می شود حدودا 34365427600
همین مقدار 34365427600 ( برای اطمینان کمی بیشتر ) را به آپشن count می دهیم.
نظر شما در این مورد چیست؟
از اینکار‌ها نکنید. معمولا یه فایل‌سیستم پیچیده‌تر از این هست که بگید با dd، یه مقدار رو رد می‌کنیم و بعد تا یه جای مشخص رو می‌خونیم و ذخیره می‌کنیم. از ابزار‌های مناسب اینکار مثل clonezila استفاده کنید.
۲- دو واژه sync و rsync در علوم کامپیوتربه یک معنا و مفهوم هستند؟
و در ضمن وقتیکه به دستور dd ، آپشن sync را می دهیم ، تنها تغییرات را اعمال می کند؟
فرق دارند. sync به معنای همگام‌سازی هست. rsync یه ابزاره که با زبان c نوشته شده. تقریبا می‌تونید اون رو نسخه ارتقا یافته دستور cp بدونید.
اون sync که توی dd هست، متفاوته. می‌تونید صفحه man مربوط به dd رو برای اطلاعات بیشتر ببینید.
man dd
۳-
در مورد مفهوم header فایل‌سیستم چیزی متوجه نمی شوم ولی اگر مثلا یک کار خیلی ساده بخواهیم انجام بدهیم بدین صورت که:
با سی دی لایو ، بوسیله copy and paste ابتدا از پاریشن ریشه ( sda3 ) کپی بگیرم و بعد پارتیشن ریشه را فرمت کنم و بعد دوباره کپی فایلهای ریشه را که در جای دیگر است را دوباره بریزم در داخل همان پارتیشن ریشه که فرمت کرده ام ، آیا بنظرتان با این روش مشکلی پیش نماید و سیستم بوت می شود و درست کار می کند؟
فایل‌سیستم باید یه جا یه سری چیز‌ها بنویسه تا بقیه برنامه‌ها (معمولا خود کرنل) متوجه بشن دارند با چی کار می‌کنند. به خاطر همین، ابتدای جایی که با یه فایل‌سیستم فرمت میشه، شامل یه سری اطلاعات مربوط به فایل‌سیستم هست تا بقیه برنامه‌ها بتونند متوجه چیزی که استفاده میشه، بشن. اگه اون اطلاعات آسیب ببینه، ممکنه برنامه‌ها نتونند فایل‌سیستم رو تشخیص بدند. علاوه بر اون چیز‌هایی که ابتدا قرار داره، چیز‌های دیگه‌ای هم (مثل super block ها) توی جاهای دیگه فایل‌سیستم وجود دارند تا فایل‌سیستم درست کار بده.
در مورد مثالی که در ادامه زدید، احتمالا لازمه فایل fstab رو ویرایش کنید چون با هر بار فرمت، uuid عوض میشه. اگه توی fstab از uuid استفاده شده باشه (که معمولا اینجوریه) اونوقت سیستم بوت نمیشه یا اگه بشه، توی initramfs گیر می‌کنید. البته می‌تونید uuid ها رو به چیز قبلی تغییر بدید تا لازم نباشه fstab رو ویرایش کنید.
اگه از lvm یا md یا dm استفاده شده باشه، احتمالا لازم میشه initramfs رو هم آپدیت کنید.
گراب رو هم به احتمال زیاد، لازمه روی دیسک نصب، و بعد تنظیماتش رو آپدیت کنید.
تغییر فایل fstab، اگه از lucks استفاده کرده باشید crypttab، نصب و آپدیت کردن تنظیماتِ گراب و آپدیت کردن initramfs معمولا کار‌هایی هست که لازمه انجام بدید. ممکنه با توجه به شرایط، بعضی از کارها لازم نباشه.
۴-
فکر می کنم در گنو/لینوکس بصورت پیش فرض از ext استفاده می کنند، بنظرتان اگر zfs دارای امکانات بهتری است ، چرا از آن استفاده نمی شود و بجای ext آنرا پیشنهاد نمی دهند؟
دلیل اصلیش، مجوز اون هست (cddl) که با مجوز کرنل (بیشتر gpl نسخه ۲) سازگار نیست. افراد مختلفی هم از zfs خوششون نمیاد. مثلا لینوس توروالدز گفته از zfs استفاده نکنید.
گراب، به طور کامل از همه قابلیت‌های zfs پشتیبانی نمی‌کنه و اگه بعضی قابلیت‌ها رو فعال کرد، دیگه گراب نمی‌تونه اونها رو بخونه. (توی zfs میشه تنظیم کرد که چه قابلیت‌هایی فعال بشن و کدوم‌ها نه)
به دلیل پشتیبانی نا کامل گراب از zfs، من از zfsbootmenu استفاده می‌کنم. این (https://github.com/zbm-dev/zfsbootmenu) لینک پروژه توی گیتهاب هست.
فعلا این پروژه، فقط برای void linux بسته بندی شدن.
از بین توزیع‌های مشهور، فعلا فقط نصاب اوبونتو رو میشناسم که از zfs پشتیبانی می‌کنه ولی هیچ قابلیت شخصی‌سازی موقع استفاده از zfs، به کاربر نمیده.
تنها توزیعی که میشناسم که قشنگ از zfs موقع نصب پشتیبانی می‌کنه و zfsbootmenu توی مخازنش وجود داره، trident، یه توزیع مبتنی بر void linux هست.
zfs توی مخازن دبیان هست (توی قسمت contrib). توی دبیان، با نصب بسته zfs-dkms، کد مربوط به ماژول‌ها اون دانلود، کامپایل و نصب میشن (مثل درایور‌های انحصاری انویدیا). به دلیل مشکل مجوزی که داره، به صورت کد منبع توی مخازن دبیان قرار گرفته. کار‌های مربوط به کامپایل اون ماژول‌ها، توسط dkms انجام میشه.
zfs توی اوبونتو، همراه خود کرنل قرار داره و لازم نیست برای داشتن ماژول‌ها اون، بسته خاصی نصب کرد. برای داشتن ابزار‌های محیط کاربر (مهم‌تر‌هاش دستورات zfs و zpool هستند) کافیه بسته zfsutils-linux رو نصب کرد.
zfs توی مخازن رسمی فدورا و rhel نیست، اما خود پروژه zfs on linux، یه مخزن برای فدورا و توزیع‌های مبتنی بر اون داره. توی فدورا، دوتا گزینه برای ماژول‌های zfs دارید، یا نسخه dkms رو بگیرید که کد دریافت و کامپایل میشه یا نسخه از پیش کامپایل شده. نسخه از پیش کامپایل شده، فقط برای کرنل‌های توی مخازن فدورا، وجود دارند.
در مورد آرچ، zfs توی aur هست. یه مخزن غیر رسمی هم zfs رو داره. توی آرچ، وضعیت شبیه فدورا هست. یعنی هم نسخه از پیش کامپایل شده دردسترسه، هم نسخه‌هایی که توسط dkms مدیریت میشن.
btrfs یه فایل‌سیستمی هست که تعداد قابل توجهی از قابلیت‌های zfs رو داره. مجوزش مشکلی نداره، به خاطر همین همراه کرنل قرار داره. از zfs، هنوز کمی کند‌تره.
میشه فایل‌سیستم‌های ext4 و btrfs رو به هم تبدیل کرد ولی اینکار بدون ریسک نیست و خیلی پیشنهاد میشه قبل از اینکار، پشتیبان بگیرید.
از بین فایل‌سیستم‌های سنتی لینوکس (خانواده ext و احتمالا xfs)، zfs و btrfs، فایل‌سیستم‌های سنتی، سرعت بیشتری نسبت به btrfs دارند. zfs با توجه به شرایط می‌تونه سریع‌تر یا کند‌تر از فایل‌سیستم‌های سنتی لینوکس باشند. از بین فایل‌سیستم‌های سنتی، xfs سریع‌تر از ext4 هست.
bcachefs هم حدود سال 2014 توسه‌اش شروع شد، نمی‌دونم الان وضعیتش چیه؛ ولی توسعه دهنده‌هاش گفتند، می‌تونه جایگزین zfs باشه.
-
من در محیط لایو توسط gparted ، به فضای Used پارتیشن ریشه‌ام یعنی sda3 نگاه کردم،که حجمش 6.17 گیگابایت بود.(عکس 1)
بعد توسط fsarchiver از sda3 ، یک فایل ایمیج گرفتم.( عکس 2 )
بعد پارتیشن sda3 را با gparted ، فرمت کردم.
بعد توسط timeshift ، پارتیشن sda3 را به حالت قبلش برگرداندم و بدون مشکلی سیستم بوت شد و دوباره برگشتم به محیط لایو و دوباره توسط gparted ، به فضای Used پارتیشن ریشه‌ام یعنی sda3 نگاه کردم،که حجمش 5.85 گیگابایت بود. ( عکس timeshift )
بعد دوباره پارتیشن sda3 را با gparted ، فرمت کردم.
بعد توسط fsarchiver خواستم sda3 توسط فایل ایمیجی که گرفته بودم را به حالت قبل برگردانم.( عکس 3 )
بعد از اتمام عملیات موردنظر در همان محیط لایو توسط gparted ، به فضای Used پارتیشن ریشه‌ام یعنی sda3 نگاه کردم،که حجمش 6.17 گیگابایت بود.(عکس fsarchiver)
ولی مشکلی که الان وجود دارد این است که با بازگردانی فایل ایمج توسط نرم‌افزار fsarchiver ،سیستم بوت نمی‌شود و در همان گراب می ماند.
اگر حوصله داشتید ، بفرمایید که چگونه در این حالت کاری کنم که سیستمم بوت شود ، تا نحوه کار با fsarchiver را تا انتها ( تا بوت شدن سیستم) یاد گرفته باشم.
اگر هم وقت نداشتید ، سیستمم را با همان timeshift به حالت قبل برگردانم.
-
۱-
در پارتیشن ریشه سیستم من در sda3 ،
۲۱ پوشه و ۴ فایل ، در اولین نگاه در پنجره اول فایل منیجر مربوط به این پارتیشن وجود دارد.
نام پوشه ها: var ، usr ، tmp ، sys ، srv ، sbin ، run ، root ، proc ، opt ، mnt ، media ، libx32 ، lib64 ، lib32 ، lib ، home ، etc ، dev ، boot ، bin
نام فایل ها : vmlinuz.old ، vmlinuz ، initrd.img.old ، initrd.img
چرا این پوشه ها خالی هستند؟ : srv ، opt ، libx32 ، lib32 ،
فایلهای vmlinuz و vmlinuz.old، به ترتیب لینک به فایل جدیدترین کرنل نصب شده و کرنل قبلی، توی /boot/ هستند. اگه فقط یه کرنل داشته باشید، هر دو فایل به همون کرنل نصب شده، لینک میشن.
initrd.img و initrd.img.old هم شبیه بالا هستند. یعنی initrd.img به فایل initramfs مربوط به جدیدترین کرنل، و initrd.img.old به فایل initramfs مربوط به کرنل قبلی لینک شده. اگه فقط یه کرنل داشته باشید، اصولا باید یه initramfs موجود باشه. در نتیجه initrd.img و initrd.img old هر دو به initramfs مربوط به کرنل نصب شده، لینک میشن.
دایرکتوری srv معمولا توسط برنامه‌هایی استفاده میشن که قراره به کامپیوتر‌های دیگه، خدمت بدند. مثلا ممکنه وب‌سرور (برای مثال nginx) نصب کرده باشید. در این حالت می‌تونید فایلهای مربوط به وبسایت‌ها رو توی srv ذخیره کنید. ممکنه یه سرویسِ پایگاه داده مثل mariadb روی کامپیوتر شما باشه، در این حالت می‌تونید داده‌ها رو توی srv ذخیره کنید.
دایرکتوری opt برای این هست تا نرم‌افزار‌های خارج از مخازن، اونجا نصب بشن. برای مثال matlab توی مخازن نیست و وقتی نصبش می‌کنید، فایلهای خودش رو داخل /opt/ میذاره.
دایرکتوری‌های lib32 و libx32 به این دلیل خالی هستند چون کتابخانه یا نرم‌افزار 32 بیتی ندارید. اگه کتابخانه‌های 32 بیتی رو نصب کنید، احتمالا فایلهای اونها توی /lib32/ قرار میگیره.
اگه معماری پردازنده شما نسخه 64 بیتی x86 باشه، می‌تونه برنامه‌هایی که برای نسخه 32 بیتی و 16 بیتی معماری x86 کامپایل شدند رو هم اجرا کنه. نسخه 32 بیتی معماری x86، توی اکثر سیستم‌عامل‌های آزاد، با اسم i386 یا i686 شناخته میشه. نسخه 64 بیتی همین معماری تکی سیستم‌عامل‌های آزاد، معمولا amd64 نام داره.
با اضافه کردن معماری i386 به لیستِ معماری‌های dpkg، می‌تونید با apt، نسخه 32 بیتی کتابخانه‌ها و برنامه‌ها رو از مخارن دریافت کنید.
می‌تونید با این دستور، معماری i386 رو به اون لیست اضافه کنید.
sudo dpkg --add-architecture i386بعد لیست مخازن رو بروز کنید و می‌تونید نسخه 32 بیتی بسته‌ها رو از مخازن نصب کنید.
sudo apt update
می‌تونید معماری‌ها رو از لیست dpkg حذف کنید. مثلا برای i386، اینجوری:
sudo dpkg --remove-architecture i386
اگه سعی کنید یه معماری که وجود نداره رو به لیست dpkg اضافه کنید، خطایی نمی‌گیرید و بدون مشکل اضافه میشه. اما در ادامه، apt اخطار میده که نمی‌تونه چیزی مرتبط با اون معماری، توی مخازن پیدا کنه.
اگه سعی کنید یه معماری که تو لیست dpkg نیست رو پاک کنید، dpkg خطا میده که نمی‌تونه اون رو پاک کنه.
به روش بالا می‌تونید معماری‌های دیگه‌ای که توسط دبیان پشتیبانی میشه (مثل arm64 یا s390x) ولی برنامه‌هایی که مربوط به اون معماری هستند، روی سیستم شما اجرا نمیشن چون پردازنده شما نمی‌تونه اونها رو اجرا کنه. ممکنه حتی نصب اون بسته‌ها با موفقیت انجام نشه.
اگه یه بسته برای چنتا معماری وجود داشته باشه، (توی دبیان اکثر بسته‌ها اینجوری هستند.) معمولا نسخه‌ای نصب میشه که با معماری پردازنده هماهنگ هست. می‌تونید با نوشتن یه دو نقطه و بعد معماری مورد نظر بعد از اسم بسته، از apt بخواهید که نسخه مربوط به یه معماری خاص رو نصب کنه. مثلا دستور زیر، نسخه‌ای از tor رو نصب می‌کنه که مربوط به معماری i386 هست.
sudo apt install tor:i386دقت کنید که معمولا، نمی‌تونید چندین نسخه برای معماری‌های مختلف از یه بسته رو همزمان نصب کنید. مثلا نسخه‌ای از بسته tor که مربوط به معماری i386 هست، با نسخه‌ای از tor که مربوط به معماری amd64 هست، تداخل داره و با نصب یکی، اون یکی پاک میشه.
البته بعضی کتابخانه‌ها، چندین نسخه برای چندین معماری دارند و تداخلی با هم ایجاد نمی‌کنند.
الان، معمولا لازم نیست پشتیبانی از معماری i386 رو توی dpkg، روی سیستم‌هایی که پردازنده با معماری amd64 دارند، فعال کنید.
م.ه اینکه بخواهید steam یا بازی‌های انحصاری رو نصب کنید. اکثر بازی‌های انحصاری، به کتابخانه‌های 32 بیتی نیاز دارند. steam هم کلا 32 بیتی هست. حداقل توی گنو/لینوکس.
۲-
وقتیکه با نرم افزار timeshift ، از سیستم snapshot می گیرم ، علاوه بر پوشه های بالایی، این پوشه ها هم خالی هستند، چرا timeshift از فایل های درون این پوشه ها هم نسخه پشتیبان تهیه نمی کند، عبارتند از : tmp ، sys ، run ، proc ، mnt ، media ، dev
( بنظر خودم پوشه media برای mount سی دی رام بکار رفته و پوشه mnt برای mount پارتیشن ها و tmp هم برای قرارگیری فایل های موقت ،به این علت timeshift آنها را خالی نگه داشته، اگر این یکی ها را درست گفته باشم، پوشه های بعدی را نمی دانم.)
media و mnt معمولا برای سوار کردن فایل‌سیستم‌ها به طور موثتی، وقتی که می‌خواهید یه کاری با اونها انجام بدید، استفاده میشن. معمولا سوار کردن‌هایی که از طریق مدیر فایل یا محیط گرافیکی انجام میدید، روی یه دایرکتوری، داخل یه دایرکتوری دیکه به اسم کاربر شما، داخل /media/ انجام میشه.
مثلا اگه یه فایل‌سیستم با یه label برابر Movies وجود داشته باشه و شما با کاربر myuser وارد شده باشید و از طریق محیط گرافیکی اون فایل‌سیستم رو سوار کنید، محل سوار شدنش می‌تونه این باشه:
/media/myuser/Moviesممکنه نام دایرکتوری آخر، برابر uuid فایل‌سیستم مورد نظر باشه. ممکنه چیز‌های مختلفی باشه. بستگی داره کدوم از اونها همراه فایل‌سیستم وجود داشته باشه.
/mnt/ معمولا برای سوار کردن دستی فایل‌سیستم‌ها استفاده میشه.
/tmp/ هم مشخصه چرا توی snapshot ها نیست. فایلهای موقتی اونجا ذخیره میشن و دلیل خاصی نیست تا اونها رو همراه snapshot ها داشته باشیم.
روی /run/ /dev/ /sys/ و /proc/، فایل‌سیستم‌های مجازی سوار میشه تا بشه از فضای کاربر (user space) تا حدودی به کرنل دسترسی داشت. محتویات اونها، موقع بالا اومدن کرنل تعیین میشه و می‌تونه در اثر قطع و وصل کردن سخت‌افزار‌ها یا تغییرات تنظیمات یا برنامه‌های مختلف، تغییر کنه. اطلاعات توی اون دایرکتوری‌ها، موقتی هست و با راه‌اندازی مجدد، از بین میره. اون اطلاعات همه روی رم ذخیره شدند. پس لازم نیست اونها رو همراه snapshot ها داشته باشیم.
به غیر از این، فکر کنم چون هر کدون از اون دایرکتوری‌ها یه محل سوار شدن (mountpoint) حساب میشن، timeshift در هر صورت اطلاعات اونها رو همراه snapshot ها ذخیره نمی‌کرد.
-
وقتیکه در محیط لایو از پارتیشن ریشه سیستم من در sda3 می خواهم ، copy and paste ، نمایم خطای عکس پایینی را می دهد.
هر چند که اکثریت فایل ها کپی می شوند ، ولی می خواستم علت این خطا را بدانم و همچنین می خواستم بدانم چه فایل هایی کپی نمی شوند؟
آیا این فایل هایی که از این طریق کپی نمی شوند در فرایند پشتیبان گیری و زمانیکه سیستم را بخواهیم restore نمایم مهمند و بایستی باشند؟
در محیط لایو و در خط فرمان با چه دستوری سیستم را می توانم ملزم به کپی گیری از آنها را نیز نمایم؟
به نظر میاد نتونسته چندین فایل که از نوع خاص هستند (احتمالا block special) رو کپی کنه. اگه روی show more detailes می‌زدید، احتمالا اطلاعات بیشتری میداد. مثل اینکه چرا نتونسته کپی کنه یا چه فایل‌هایی بودن که این اتفاق برای اونها افتاده.
-
چند روزی است که افتادم طبق معمول به جان سیستم و هی فرمتش می کنم ،البته در این بین به نتایجی هم رسیده ام و مطالبی را آموخته ام ، حیفم آمد آنها را در اختیار دوستان قرار ندهم، شاید یکیش بدردتان بخورد.( ماشاا... اونقدر دانشمندید که موشک هوا می کنید ، این مسایل پیش پا افتاده به چه دردتان خواهد خورد ولی بهرحال.)
البته چون به این موضوع علاقمندم ، از پایین ترین سطح شروع می کنم و ان شاء ا... همین طوری می روم جلو، مطالبی که در اینجا آورده ام به هیچ عنوان کپی برداری صرف از اینترنت نبوده و بر روی سیستم خودم به طرق های گوناگون بارها آزموده ام .
دوستان اگر از نظرات اصلاحی و راهنماییهایشان مرا برخوردار نمایند، مثل همیشه ممنون و متشکر خواهم بود.
الف) backup و restore با cp :
همه این کارها را در محیط لایو انجام دهید.
۱- ابتدا توسط این فرمان از پارتیشن موردنظرتان بک آپ بگیرید:
cp -afrp path/to/root /path/to/destination
توچه کنید که با این فرمان در مقصدتان یک پوشه ای با نام UUID پارتیشن مبدا ایجاد خواهد شد که در داخل آن پوشه ها و فایل های ریشه اتان خواهد بود.
اگر هم دوست نداشته باشید که پوشه ای با نام UUID پارتیشن مبدا برایتان ایجاد شود از این دستور استفاده نمایید، تا پوشه ها و فایل ها ی مبدا، بدون ایجاد این پوشه در مقصدتان کپی شود( حتما در اینصورت ،علامت */ در انتهای مسیر مبدا را بگذارید.):
(عکس ۱)
cp -afrp path/to/root/* /path/to/destination
اگر هم دوست داشته باشید از انچه در حال انجام است را نمایش دهد از آپشن v استفاده نمایید، که در اینجا afrpv- می شود .
۲- زمانیکه هم خواستید با این دستور سیستم را به حالت قبل برگردانید، جای دو تا مسیر را با هم عوض کنید و چون نمی خواهیم خود پوشه بک آپ انتقال یابد و تنها
می خواهیم محتویات پوشه بک آپ انتقال یابد،علامت */ در انتهای مسیر مبدا را بگذارید.( عکس ۲)
cp -afrp /path/to/backup/* path/to/root
تذکر: برای استفاده از این روش ، لازم است که هر دو مسیر در حالت mount باشند.
تذکر: از این روش تنها در محیط لایو برای پشتیبان گیری و restore کردن سیستم اصلی تان استفاده نمایید.
تذکر: چون حجم فایل ها زیاد است مدت زمانی طول می کشد که فایل ها از حافظه میانگیر یا بافر (Buffer) به روی هاردتان ذخیره گردند و بایستی حتما قبل از بستن پنجره ها
و یا خروج از سیستم نسبت به این امر مطمئن شوید.
بطور کلی برای اینکه مطمئن شویم چه در زمان backup گیری و چه در زمان restore ، که تعداد فایل های مبدا با مقصد یکی باشند از دستور tree استفاده می نماییم.
اگر بر روی سیستممان نصب نیست ابتدا با دستور sudo apt install tree آنرا نصب می نماییم و بعد به عنوان آرگومان یکبار به دستور tree ، مبدا را می دهیم و یکبار دیگر مقصد را . در انتهای خروجی دستور tree ، تعداد directories و files مربوط به مسیر داده شده را نشان می دهد. سپس فایل های مبدا و مقصد را باهم از لحاظ تعداد دایرکتوری و فایل با هم مقایسه می نماییم.( عکسهای tree1 و tree2 )
تذکر: در بالا برای فرمان cp بایستی حتما آپشن های afrp- را بکار ببرید، اگر آنها را بکار نبرید بعد از بالا آمدن سیستم اصلی در بعضی زمینه ها از قبیل مجوزها و...
دچار مشکل خواهید بود . ( عکس sudo )
تذکر مهم: اگر پوشه ها و فایل های پارتیشن اصلی تان را در محیط لایو همین طوری با delete + shift حذف کردید ، تنها فقط همان restore کردن در محیط لایو کفایت می کند و نیازی به
مراحل پایینی ندارید.
تذکر: ولی اگر زمانی پارتیشن ریشه را فرمت کردید و سپس خواستید سیستمتان را restore نمایید،لازم است که علاوه بر مراحل بالایی ، مراحل زیر را هم انجام بدهید:
- چون uuid پارتیشن ریشه با هر بار فرمت کردن عوض می شود ، بایستی در فایل fstab بروید و uuid قبلی پارتیشن / را به uuid جدیدش تغییر بدهید.
یک عکس هم در این مورد گذاشته ام و یکی قبل از فرمت پارتیشن و دیگری بعد از فرمت پارتیشن می باشد و بوضوح نشان می دهد که uuid پارتیشن تغییر کرده است.( عکس 3)
کار سختی هم نیست برای پیدا کردن uuid مثلا اگر پارتیشن / در sda3 باشد از این دستور استفاده کنید، فرقی ندارد چه در محیط سیستم اصلی تان و چه در محیط لایو ،باشید، جواب یکی است :
blkid /dev/sda3
بعد از پیدا کردن uuid بروید و با ویرایشگرتان در فایل fstab و uuid را تغییر بدهید. ( عکس 4 و 5 و 6)
- بایستی grub را آپدیت نمایید. در همین لینوکس مینت که بصورت لایو بالا آمده است ، بصورت پیش فرض نرم افزار گرافیکی بنام Boot Repair وجود دارد که
از آن می توانید ، استفاده نمایید، چونکه اگر اینکار را نکنید، سیستمتان بوت نخواهد شد.( عکس های 7 , 8 , 9 , 10 , 11 )
به راحتی بر روی گزینه Recommended repair کلیک کنید ، تا خودش همه کارها را انجام بدهد.
اگر هم بخواهید بدانید که این Boot Repair چه کاری انجام داده ، ایجاد پوشه ای بنام Boot در پوشه EFI می باشد. پوشه ای بنام Boot توسط نرم افزار Boot Repair با سه فایل درونش ایجاد شده است.( عکس 12 )
-
ادامه عکسهای مربوط به ( backup و restore با cp ) :
-
ادامه عکسهای مربوط به ( backup و restore با cp ) :
-
روشی دیگر برای تعمیر و آپدیت گراب در حالت EFI :
همچنانکه در بالا توضیح دادم ، اگر از سیستمتان با روشهای cp , rsync و یا fsarchiver و ... بک آپ بگیرید و سپس پارتیشن ریشه سیستمتان را فرمت نمایید و بعد از آن اقدام به restore فایل های بک آپ به پارتیشن ریشه نمایید، سیستمتان بوت نمی شود . چون uuid پارتیشن ها با فرمت کردن تغییر می نمایند.
اگر دبیان نصب کرده اید در داخل پوشه EFI که مربوط به boot کردن سیستم شماست ، پوشه ای بنام debian وجود دارد.که فایل های مربوط به efi و boot و grub در داخل همین
پوشه debian هستند.در بالا من برای حل این موضوع از نرم افزار Boot Repair که بصورت پیش فرض در لینوکس مینت نصب است ، استفاده کردم با این کار پوشه ای بنام boot در کنار همین پوشه debian ایجاد می گردد. ولی من دوباره می خواهم از روش دیگری استفاده نمایم و اصل موضوع را برای شما نشان بدهم که مشکل در کجاست و سپس به سادگی
این مورد را با روش دیگری حل بکنم.در این حالت برخلاف استفاده از نرم افزار Boot Repair ، هیچ فایل یا پوشه ای به سیستمتان اضافه نمی شود. مراحل کار را با عکس برای شما نشان داده ام .
توصیح آنکه پارتیشن ریشه من در sda3 و همچنین پارتیشن EFI سیستم من در sda1 می باشد.
-
ب) backup و restore با rsync :
در ویکی آرچ در این مورد به حد کافی توضیح داده شده است:
https://wiki.archlinux.org/title/rsync (https://wiki.archlinux.org/title/rsync)
وقتیکه موارد مربوطه به این صفحه خوانده می شود ، ما بین این صفحه و عملکرد timeshift ، شباهت های فراوانی مشاهده می شود.
-
با تشکر فراوان از آقایان Dragon- و دانیال بهزادی .
-
بعد توسط timeshift ، پارتیشن sda3 را به حالت قبلش برگرداندم و بدون مشکلی سیستم بوت شد و دوباره برگشتم به محیط لایو و دوباره توسط gparted ، به فضای Used پارتیشن ریشه‌ام یعنی sda3 نگاه کردم،که حجمش 5.85 گیگابایت بود. ( عکس timeshift )
بعد دوباره پارتیشن sda3 را با gparted ، فرمت کردم.
وقتی پارتیشن رو فرمت کردید، uuid اون به همراه اطلاعات فایل‌سیستم عوض/پاک شدند. بعد که با timeshift به حالت قبل برگشتید، احتمالا timeshift دوباره uuid رو به حالت قبل برگردونده و سیستم بدون مشکل بوت شده.
دلیل تفاوت حجم‌ها احتمالا این بوده که timeshift، فایلهای موقتی رو همراه پشتیبان‌ها ذخیره نکرده.
بعد توسط fsarchiver خواستم sda3 توسط فایل ایمیجی که گرفته بودم را به حالت قبل برگردانم.( عکس 3 )
بعد از اتمام عملیات موردنظر در همان محیط لایو توسط gparted ، به فضای Used پارتیشن ریشه‌ام یعنی sda3 نگاه کردم،که حجمش 6.17 گیگابایت بود.(عکس fsarchiver)
ولی مشکلی که الان وجود دارد این است که با بازگردانی فایل ایمج توسط نرم‌افزار fsarchiver ،سیستم بوت نمی‌شود و در همان گراب می ماند.
فکر کنم fsarchiver به طور پیش‌فرض به uuid کار نداره و به خاطر همین، uuid توی حالت‌های مختلف، متفاوت بوده.
در مورد حجم هم مشخصه چرا مثل قبل بوده. fsarchiver همه چیز‌های داخل اون پارتیشن رو ذخیره کرده و کاری هم به اینکه بعضی فایل‌ها موقتی بودند، نداشته.
وقتی توی گراب گیر می‌کردید چه اتفاقی می‌افتاد؟ چیزی شبیه grub rescue می‌دیدید؟ احتمالا یه خط فرمان باز میشده و از شما می‌خولسته تا چیز وارد کنید، درسته؟
توی سیستم‌های uefi، فایل اجرایی گراب توی esp ذخیره میشه (EFI system partition)، معمولا همراه فایل اجرایی گراب، یه فایل متنی کوچک هم هست. اون فایل سعی می‌کنه تنظیمات اصلی گراب رو بارگذاری کنه.
تنظیمات اصلی گراب، بسته به توزیع توی یکی از مسیر‌‌های زیر قرار داره.
/boot/grub/grub.cfg
/boot/grub2/grub2.cfgمعمولا توی دبیان و توزیع‌های مبتنی بر اون، اولی استفاده میشه و توی فدورا و توزیع‌های مبتنی بر اون، از دومی.
اون فایل تنظیمات کوچک که همراه گراب توی esp قرار داره، اول سعی می‌کنه روت رو برابر فایل‌سیستمی قرار بده که تنظیمات گراب داخلش قرار دارند. و بعد هم تنظیمات رو بارگذاری کنه. معمولا از uuid برای پیدا کردن اون فایل‌سیستم استفاده میشه.
توی حالت شما، /boot/grub/ جزی از روت دبیان بوده. در نتیجه توی اون فایل کوچک، uuid که استفاده شده بوده، uuid مربوط به فایل‌سیستم روت شما بوده.
وقتی uuid تغییر کرده، گراب هم نمی‌تونسته تنظیمات اصلیش رو بارگذاری کنه و در نتیجه یه خط فرمان به شما میداده تا کارها رو درست کنید.
اون فایل کوچک و فایل اجرایی گراب که داخل esp وجود دارند، معمولا توسط grub-install اونجا گذاشته شدند.
اگر حوصله داشتید ، بفرمایید که چگونه در این حالت کاری کنم که سیستمم بوت شود ، تا نحوه کار با fsarchiver را تا انتها ( تا بوت شدن سیستم) یاد گرفته باشم.
یا باید یه جوری uuid رو همراه پشتیبان‌های fsarchiver ذخیره کنید تا بعدا موقع برگردوندن پارتیشن، uuid مثل قبل بشه یا اینکه تنظیمات گراب رو درست کنید.
-
چند روزی است که افتادم طبق معمول به جان سیستم و هی فرمتش می کنم ،البته در این بین به نتایجی هم رسیده ام و مطالبی را آموخته ام ، حیفم آمد آنها را در اختیار دوستان قرار ندهم، شاید یکیش بدردتان بخورد.
...
الف) backup و restore با cp :
به نظرم rsync گزینه بهتری هست چون می‌تونه acl های فایل‌ها رو موقع فرستادن حفظ کنه. journald از acl ها برای اینکه دسترسی به گزارش‌ها (لاگ‌ها) رو مدیریت کنه، استفاده می‌کنه. فکر نکنم cp بتونه acl ها رو منتقل کنه.
rsync فقط فایل‌هایی رو کپی می‌کنه که یا توی مقصد نیستند یا اینکه توی مقصد و مبدا با هم تفاوت دارند. البته اگه توی مقصد چیزی وجود نداشته باشه یا اکثر فایل‌ها توی مقصد و مبدا متفاوت باشند، این مزیت به درد نمی‌خوره.
در حالتی که از قبل پشتیبان گرفته باشید و بخواهید یه جدید بگیرید و فقط فایل‌هایی که تغییر کرده باشند رو کپی کنید، این قابلیت می‌تونه خیلی توی زمان، صرفه جویی کنه.
من خودم اینجوری از rsync برای پشتیبانی گرفتن از روت یه سیستم استفاده می‌کنم.
rsync -aAXUH path/to/root/ /path/to/destinationاگه اون اِسلش (علامت /) آخر رو بذارید، محتوای path/to/root کپی میشه. اگه اسلش آخر رو نذارید، خود دایرکتوری کپی میشه و فایل‌ها درون اون قرار میگیرن. دستور بالا، فایل‌ها و دایرکتوری‌های مخفی رو هم کپی می‌کنه.
آپشن a- خیلی چیز‌ها از جمله دسترسی‌ها، مالکیت و اینجور چیز‌ها رو حفظ می‌کنه. A- برای این هست تا acl ها هم حفظ بشن، X- برای حفظ xattr ها هست، U- باعث میشه تا زمان‌هایی که فایل تغییر کرده هم حفظ بشه و H- باعث میشه لینک‌های سخت توی مبدا هم ایجاد بشن.
H- رو می‌تونید بردارید تا سرعت یکم بیشتر بشه. ولی با توجه به شرایط، ممکنه باعث بشه حجم بیشتری توی مبدا اشغال بشه. معمولا اینجوری نیست، مگه اینکه لینک‌های سخت زیادی داشته باشید و فایل‌ها مربوط به اون لینک‌ها، حجیم باشند.
در صورتی که بخواهید rsync بگه که داره چیکار می‌کنه، می‌تونید آپشن v- رو بدید. با دادن آپشن h-، خروجی بهتری نمایش داده میشه تا یه آدم راحت‌تر متوجه بشه. اگه h- رو بدون هیچ چیز دیگه‌ای به rsync بدید، راهنمای کوتاه rsync نمایش داده میشه.
در صورتی که آپشن N- رو به rsync بدید، زمانی که فایل‌ها ایجاد شدند، موقع کپی کردن حفظ میشه. البته برای اینکه این قابلیت کار کنه، باید موقع کامپایلِ برنامه، فعال شده باشه. نسخه‌ای از rsync که توی مخازن دبیان هست، این قابلیت رو نداره چون موقع کامپایل، این قابلیت فعال نبوده.
همه این کارها را در محیط لایو انجام دهید.
میشه توی سیستم اصلی، وقتی که بوت شده انجامش داد ولی باید بدونید دارید چیکار می‌کنید تا یه پشتیبان بدون مشکل و سالم بگیرید.
۱- ابتدا توسط این فرمان از پارتیشن موردنظرتان بک آپ بگیرید:
cp -afrp path/to/root /path/to/destination
بهتر بود اینجا می‌گفتید path/to/root، مسیر به جایی هست که فایل‌سیستم مورد نظر سوار شده و /path/to/destination/، مسیر به دایرکتوری مقصد هست؛ جایی که می‌خواهیم پشتیبان رو ذخیره کنیم. اگه یه کاربر همینجوری این دستورات رو بزنه، به احتمال خیلی زیاد خطا میگیره که چنین فایل یا دایرکتوری وجود نداره.
توی cp، آپشن a- معادل Rd --preserve=all- هست. R- و r- با هم برابر هستند. p- برابر preserve=mode,ownership,timestamps-- هست. با توجه به اینها، r- توی دستور شما زیادیه، p- هم همینطور چون preserve=all-- هرچی رو بتونه، منتقل می‌کنه، در نتیجه دسترسی، مالکیت، گروه و زمان‌ها هم حفظ میشه. پس دستور شما می‌تونه به این شکل ساده بشه:
cp -af path/to/root /path/to/destination
دستور بالا دایرکتوری path/to/root رو کپی می‌کنه توی /path/to/destination/، توی این کپی کردن، بیشتر مشخصات فایل‌ها و دایرکتوری‌ها حفط میشن. منظورم از مشخصات، چیز‌های مثل دسترسی، مالکیت، timestamp ها و اینجور چیز‌هاست. خود فایل‌ها همیشه کپی میشن.
با احتیاط از آپشن f- توی cp استفاده کنید. چون باعث میشه حتی اگه فایلی هم توی مقصد بود و هم توی مبدا، اطلاعات اونی که توی مبدا هست، روی فایلی که توی مقصد هست، نوشته بشه.
توچه کنید که با این فرمان در مقصدتان یک پوشه ای با نام UUID پارتیشن مبدا ایجاد خواهد شد که در داخل آن پوشه ها و فایل های ریشه اتان خواهد بود.
البته این در حالتی درسته که اسم دایرکتوری path/to/root با uuid اون فایل‌سیستم برابر باشه. همیشه اینطوری نیست، مثلا ممکنه فایل‌سیستم مورد نظر رو دستی روی /mnt/ سوار کرده باشید، بعد از استفاده از دستوری که گذاشتید، توی مبدا یه دایرکتوری به اسم mnt ایجاد میشه.
معمولا وقتی از طریق محیط گرافیکی یا مدیرفایل‌های گرافیکی مثل nautilus، dolphin و ... یه چیزی رو سوار می‌کنید، یه دایرکتوری توی /media/ به اسم کاربر شما ایجاد میشه. توی اون دایرکتوری، یه دایرکتوری دیگه با uuid فایل‌سیستم مورد نظر ایجاد میشه و بعد اون فایل‌سیستم، روی دایرکتوری آخری که گفتم، سوار میشه.
ممکنه اسم اون دایرکتوری آخری که ساخته میشه، برابر label یا یه مشخصه دیگه فایل‌سیستم باشه. پس اینکه بگید توی مقصد، یه دایرکتوری با اسمی برابر uuid فایل‌سیستم مبدا درست میشه، همیشه درست نیست.
وقتی میگید 'uuid پارتیشن مبدا'، به نظر میرسه منظور، uuid خود پارتیشن هست که به اطلاعات روی پارتیشن، بستگی نداره. در حالی که منظور ما، uuid خود فایل‌سیستم هست.
بهتره به جای پارتیشن بگید فایل‌سیستم. چون اون uuid که می‌بینید، مربوط به خود فایل‌سیستم هست. مال پارتیشن نیست.
میشه روی یه پارتیشن، lucks (برای رمزنگاری) ایجاد کرد. با اینکار، یه دستگاه مجازی توی /dev/ ایجاد میشه تا بتونید از این فضای رمزنگاری شده استفاده کنید.
الان می‌تونید مثل وقتی که یه پارتیشن رو فرمت می‌کنید، این دستگاه مجازی رو با یه فایل‌سیستم فرمت کنید. (در صورتی که کلید اون lucks، لود شده باشه) معمولا فایل‌سیستم برای خودش یه uuid ایجاد می‌کنه، شما می‌تونید مثل قبل، از این uuid توی فایل fstab استفاده کنید. البته باید توی فایل crypttab تنظیم کنید که این lucks باز بشه، در غیر اینصورت، فایل‌سیستمی با اون uuid پیدا نمیشه و یه جایی توی مراحل بوت، به مشکل می‌خورید.
در مورد دستگاه‌های مجازی md (مربوط به raid) باز هم همینجوره. یعنی شما چندین پارتیشن یا دیسک رو برای raid استفاده می‌کنید و نتیجه میشه یه دستگاه مجازی، توی /dev/، بعد می‌تونید اون دستگاه مجازی رو فرمت کنید، یا بدیدش به lucks یا کار‌های دیگه باهاش انجام بدید.
lvm هم شبیه همین هست.
حتی می‌تونید اینها رو ترکیب کنید. مثلا با چنتا دیسک، raid بسازید که باعث میشه یه دستگاه مجازی توی /dev/ ساخته بشه، بعد از lvm استفاده کنید که می‌تونه چندین دستگاه مجازی دیگه، به /dev/ اضافه کنه. بعد همه یا بعضی از اونها رو با lucks رمزنگاری کنید که یک یا چنتا دستگاه مجازی دیگه هم اضافه میشه و بعد اون دستگاه‌های مجازی آخری رو با یه فایل‌سیستم فرمت کنید.
می‌تونید ترتیب رو هم عوض کنید، مثلا اول lucks باشه، بعد lvm یا چیز‌های دیگه.
اگه از پارتیشن‌تیبل gpt استفاده شده باشه، هر پارتیشن فاقد از اینکه با چی فرمت شده، یا چه اطلاعاتی روی اون هست، یه uuid مخصوص به خودش داره. (ممکنه بهش guid هم بگن، توی این مورد فرقی ندارند)
توی سیستم‌عامل‌های آزاد، معمولا به اسم PARTUUID شناخته میشه. میشه از این PARTUUID توی فایلهای fstab یا crypttab استفاده کرد. مثلا این شکلی برای fstab
PARTUUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /home ext4 rw,defaults 0 0
به جای xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx، باید uuid اون پارتیشن قرار بگیره.
uuid مربوط به پارتیشن‌ها رو می‌تونید توی /dev/ پیدا کنید. توی این مسیر:
/dev/disk/by-partuuid
توی دایرکتوری بالا، لینک‌هایی وجود داره که به فایل اصلی پارتیشن، توی /dev/ اشاره می‌کنند. اسم اون لینک‌ها، برابر uuid پارتیشنی هست که بهش اشاره میشه.
blkid و lsblk هم می‌تونند partuuid رو نمایش بدهند.
اگر هم دوست نداشته باشید که پوشه ای با نام UUID پارتیشن مبدا برایتان ایجاد شود از این دستور استفاده نمایید، تا پوشه ها و فایل ها ی مبدا، بدون ایجاد این پوشه در مقصدتان کپی شود( حتما در اینصورت ،علامت */ در انتهای مسیر مبدا را بگذارید.):
(عکس ۱)cp -afrp path/to/root/* /path/to/destination
گزینه بهتر اینه:
cp -af path/to/root/. /path/to/destination
اینجوری فایل‌ها و دایرکتوری‌های مخفی هم کپی میشن. البته معمولا بعیده که فایل یا دایرکتوری مخفی توی روت یه سیستم وجود داشته باشه.
تا جایی که می‌دونم، فقط selinux هست که توی روت، فایل مخفی ایجاد می‌کنه. selinux اینکار رو انجام میده تا توی بوت بعدی، برای فایل‌ها label بذاره. ( تا بتونه درست کار کنه) بعد از اینکه اینکار رو انجام داد، اون فایل رو پاک می‌کنه.
فایلی که ایجاد میشه، خالی هست و اسمش اینه autorelabel.
میشه با touch این فایل رو ایجاد کرد. با ابزار‌های selinux هم ممکنه. اینجوری:
fixfiles -F onboot
در مورد دایرکتوری مخفی هم فقط یه zfs رو می‌دونم که یه دایرکتوری با اسم zfs. توی روتِ هر dataset معمولی میسازه. در نتیجه اگه روتِ سیستم، از zfs استفاده کنه، یه دایرکتوری به اسم zfs. هم ایجاد میشه. این دایرکتوری برای این هست تا بشه به اطلاعات snapshot های قبلی دسترسی داشت. قسمت جالبش اینه که به طور پیش‌فرض، ls -a هم اون رو نشون نمیده. ولی اگه اسم کاملش رو بدید، نشون میده. این رفتار رو میشه تغییر داد.
۲- زمانیکه هم خواستید با این دستور سیستم را به حالت قبل برگردانید، جای دو تا مسیر را با هم عوض کنید و چون نمی خواهیم خود پوشه بک آپ انتقال یابد و تنها
می خواهیم محتویات پوشه بک آپ انتقال یابد،علامت */ در انتهای مسیر مبدا را بگذارید.( عکس ۲)
cp -afrp /path/to/backup/* path/to/root
اگه از rsync استفاده کرده باشید، می‌تونید اینجوری اطلاعات رو برگردونید.
rsync -aAXUH /path/to/backup/ path/to/rootهمونطور که بالا گفتم، اون اسلش (علامت /) آخر رو باید بذارید تا محتوای داخل اون دایرکتوری کپی بشه.
اگه از cp می‌خواهید استفاده کنید، اینجوری انجام بدید تا فایل‌ها و دایرکتوری‌های مخفی هم کپی بشن.
cp -af /path/to/backup/. path/to/root
تذکر: برای استفاده از این روش ، لازم است که هر دو مسیر در حالت mount باشند.
بهتر بود این رو بالاتر می‌گفتید، همون اول کار قبل از اینکه cp رو معرفی کنید.
اینکه بگید 'لازم است هر دو مسیر در حالت mount باشند'، زیاد واضح نیست. بهتره بگید ' لازم است که فایل‌سیستم مورد نظر سوار شده باشد'
لازم نیست جایی که می‌خواهید پشتیبان‌ها رو ذخیره کنید، حتما یه 'محل سوار شدن' (mountpoint) باشه.
برای مثال ممکنه شما بخواهید پشتیبان‌ها رو روی یه فلش ذخیره کنید.
فرض کردیم فایل‌سیستمی که قرار پشتیبان‌ها روی اون ذخیره بشن، روی /mnt/usb-storage/ سوار شده و فایل‌سیستمی که می‌خواهیم از اون پشتیبان بگیریم، روی /mnt/debian-root/
باز هم فرض می‌کنیم که قراره پشتیبان‌های دبیان رو توی فلش، توی یه دایرکتوری به اسم debian-back ذخیره کنیم تا پشتیبان‌ها یه نظمی داشته باشند.
برای اینکه ببینید هر پشتیبان کِی گرفته شده، یه دایرکتوری می‌سازید که اسم اون، برابر تاریخ پشتیبان‌گیری هست. مثلا این: 11-02-2022
با این فرض‌ها، مسیری که قراره فایل‌ها توی اون ذخیره بشن، میشه این:
/mnt/usb-storage/debian-back/2022-02-11همینطور که می‌بینید، مسیر بالا یه محل سوار شدن (mountpoint) نیست. بلکه /mnt/usb-storage/ یه محل سوار شدن هست.
تذکر: چون حجم فایل ها زیاد است مدت زمانی طول می کشد که فایل ها از حافظه میانگیر یا بافر (Buffer) به روی هاردتان ذخیره گردند و بایستی حتما قبل از بستن پنجره ها و یا خروج از سیستم نسبت به این امر مطمئن شوید.
می‌تونید از دستور sync برای اینکار استفاده کنید. اگه دستور sync رو اجرا کنید، اطلاعات از توی cache/buffer روی حافظه ذخیره‌سازی نوشته میشن.
تا وقتی که فایل‌سیستم پایان این نوشتن رو اعلام نکنه، دستور sync به پایان نمیرسه. اینجوری می‌تونید متوجه بشید که کِی عملیات نوشتن تموم شده و بیهوده صبر نکنید.
بطور کلی برای اینکه مطمئن شویم چه در زمان backup گیری و چه در زمان restore ، که تعداد فایل های مبدا با مقصد یکی باشند از دستور tree استفاده می نماییم.
به نظرم diff گزینه مناسب‌تری برای اینکار هست. چون اگه یه فایلی هم توی مقصد باشه و هم توی مبدا اما متفاوت باشند، (مثلا ناقص منتقل شده باشه) شما با استفاده از tree نمی‌تونید متوجه این بشید. در حالی که اگه از diff استفاده کرده باشید، میگه که دقیقا چه فایل‌ها یا دایرکتوری‌هایی با هم متفاوت هستند.
diff رو همراه آپشن‌های q- و r- و با دادن دوتا دایرکتوری مورد نظر اجرا کنید تا بگه چه فایل‌هایی توی اون دوتا دایرکتوری با هم متفاوته.
مثلا اینجوری:
diff -qr /mnt/debian-root /mnt/usb-storage/debian-back/2022-02-11آپشن q- برای این هست تا تفاوت‌ها رو نشون نده و فقط بگه چه فایل‌هایی با هم متفاوت هستند. r- برای این هست که مقایسه به صورت بازگشتی انجام بشه و زیر دایرکتوری‌ها و فایلهای داخل اونها هم بررسی بشن.
تذکر: ولی اگر زمانی پارتیشن ریشه را فرمت کردید و سپس خواستید سیستمتان را restore نمایید،لازم است که علاوه بر مراحل بالایی ، مراحل زیر را هم انجام بدهید:
شاید لازم باشه initramfs رو هم دوباره ایجاد کنید. ممکنه فایل‌سیستم روت، توی خود initramfs مشخص شده باشه. اگه از lvm یا lucks یا چیز‌های دیگه هم استفاده کرده باشید، احتمالا باز هم لازمه تا initramfs رو دوباره ایجاد کنید.
کار سختی هم نیست برای پیدا کردن uuid مثلا اگر پارتیشن / در sda3 باشد از این دستور استفاده کنید، فرقی ندارد چه در محیط سیستم اصلی تان و چه در محیط لایو ،باشید، جواب یکی است :
blkid /dev/sda3
با lsblk هم می‌تونید اینکار رو انجام بدید. حتی میشه فقط uuid رو گرفت. اینجوری
lsblk -o UUID /dev/sda3
ولی lsblk یه مشکل داره و partuuid (و احتمالا uuid) رو توی محیط chroot نشون نمیده. حتی با اینکه فایل‌سیستم‌های مورد نیاز هم سوار بودند.
- بایستی grub را آپدیت نمایید.
علاوه بر آپدیت کردن گراب، باید فایل تنظیم اون توی esp رو هم تغییر بدید. (اگه سیستم توی حالت uefi بوت شده)
توی ارسال بالا یه سری توضیح دادم.
در مورد boot repair، توی کامپیوتر شما، گراب رو توی مسیر پیش‌فرض قرار داده. احتمالا متغیر‌های EFI رو هم تغییر داده.
دلیل اینکه گراب رو توی مسیر پیش‌فرض گذاشته این هست که بعضی پیاده سازی‌های uefi، مشکل دارند و الویت بوت رو بر اساس متغیر‌های EFI انجام نمیدن. و فقط چیزی که توی مسیر پیش‌فرض هست رو بوت می‌کنند.
بعضی اوقات، boot repair می‌تونه نتایج ناخواسته داشته باشه. (مخصوصا اگه نخواهید از گراب استفاده کنید) به خاطر همین بهتره با احتیاط ازش استفاده کنید و بعد از استفاده، چیز‌ها رو بررسی کنید تا ببینید مطابق چیزی هست که می‌خواهید یا نه.
-
با سپاس مجدد از آقای Dragon- عزیز، دستتان درد نکنه خیلی زحمت کشیدید.