القرص المُلحَق بخادم افتراضي يظهر جهازًا ولا شيء غير ذلك. فما لم يُهيَّأ ويُركَّب فهو لا يحمل شيئًا ولا يشير إليه أي مجلّد، ولهذا يبدو القرصُ المُلحَق حديثًا كأنه لم ينجح.
انظر ما المُلحَق
lsblk -fالجهاز الجديد بلا FSTYPE وبلا MOUNTPOINT. وبهذا تميّزه من قرص النظام الذي يحمل نظام ملفّات بالفعل.
هيّئه
sudo mkfs.ext4 -L data /dev/sdbشغِّل هذا على الجهاز الخطأ فتذهب بياناته بلا سؤال ولا تراجع. أعد قراءة خَرْج lsblk وتأكّد أن الحجم يطابق القرص الذي ألحقته لتوّك.
نظامُ ملفّاتٍ على الجهاز كلّه بلا جدول أقسام أمرٌ معتاد في أقراص السحابة، وهو يسهّل توسيعه لاحقًا. ولا تقسّم إلّا إن كان شيءٌ آخر يتوقّع قسمًا.
ركِّبه
sudo mkdir -p /srv/data
sudo mount /dev/sdb /srv/data
df -h /srv/dataالخطوة التي يَنساها الناس
التركيبُ باليد يزول عند إعادة التشغيل التالية، فيعود المجلّد مجلّدًا فارغًا على قرص النظام — ثمّ يمتلئ قرص النظام والقرصُ الآخر عاطل. اكتبه في fstab بالمعرّف UUID، لأن أسماء الأجهزة قد يتغيّر ترتيبها بين إقلاع وآخر.
sudo blkid /dev/sdb
# UUID="0a1b2c3d-..." TYPE="ext4"
echo 'UUID=0a1b2c3d-... /srv/data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -aالخيار nofail يدع الجهاز يُقلع وإن غاب القرص. وبدونه يعلق الخادم عند الإقلاع إذا فُصل القرص، وعلى خادم افتراضي بلا وحدة تحكّم فتلك تذكرة دعم.
انقل البيانات إليه
- أوقف ما يكتب هناك — قاعدة البيانات أو خادم الويب، حتى لا يتغيّر شيء في أثناء النسخ.
- انسخ والأذونات سليمة —
sudo rsync -aHAX /var/lib/mysql/ /srv/data/mysql/ - وجّه الخدمة إلى المسار الجديد — ثم شغّلها من جديد.
- أبقِ النسخة القديمة حتى يثبت الجديد — غيّر اسمها بدل أن تحذفها، واحذفها بعد أسبوع.