استخدام Storage Server لموقعكم الخاص: الصور والتنزيلات والأرشيف
المساحة على خادم الويب غالية، وعلى Storage Server ليست كذلك. يعرض هذا المقال ما يمكن نقله، وأي بروتوكول يعمل من خادم الويب، وكيف تصل الملفات إلى الزوّار بشكل آمن.
مساحة القرص في خادم الويب هي أغلى ما فيه. فهي تقوم على أقراص NVMe-SSD سريعة مبنية لقواعد البيانات وPHP، ويزداد ثمنها بشكل ملموس مع كل جيجابايت. وفي الوقت نفسه تقبع هناك أشياء لا تحتاج هذه السرعة أبداً: الصور الأصلية، وملفات الفيديو، وأرشيفات التنزيل، والنسخ الاحتياطية القديمة.
يكلّف Storage Server جزءاً صغيراً من ذلك، ويأخذ عنكم هذا الحمل بالضبط. يعرض هذا المقال ما يستحق النقل فعلاً، وأي بروتوكول يعمل من خادم الويب، وكيف تصل الملفات إلى الزوّار بشكل آمن، وأين تقع الحدود.
ما يستحق النقل وما لا يستحق
| يُوضع على خادم التخزين | يبقى على خادم الويب |
|---|---|
| أصول الصور ومقاطع الفيديو | الصور المصغّرة والنسخ المقتطعة |
| أرشيفات التنزيل وملفات ISO ومجموعات PDF | CSS وJavaScript والخطوط |
| البيانات الخام وملفات التصدير وأرشيفات السجلات | قاعدة البيانات |
| النسخ الاحتياطية للموقع | كل ما يُحتاج إليه عند كل استدعاء للصفحة |
خط الفصل بسيط: ما يُقرأ قليلاً ويُنقل مرة واحدة بحجم كبير يُوضع على خادم التخزين. وما يُحمَّل مع كل استدعاء للصفحة يبقى حيث السرعة.
ما هو Storage Server وما ليس هو
إن Storage Server تخزين شبكي بحسابات مستخدمين. تتصلون ببيانات دخول، ثم تقرأون الملفات أو تكتبونها. وهو ليس تخزيناً كائنياً بعناوين عامة، وليس شبكة CDN.
وعملياً يعني ذلك: لا يمكنكم في موقعكم ربط صورة بخادم التخزين مباشرةً، لأن كل وصول يتطلب تسجيل الدخول. فخادم الويب لديكم يجلب الملف ويمرّره، أو تُنشئون بأنفسكم روابط تنزيل محدودة زمنياً. وكيف يتم ذلك بشكل سليم، فهذا موضح أدناه.
يبدو هذا قيداً، لكن فيه ميزة: لا أحد يستطيع أن يسحب ملفاتكم بتخمين العناوين أو بتمرير رابط. فالوصول يمر دائماً عبر تطبيقكم، أي عبر قواعدكم.
النمط الذي يعمل في الواقع العملي
ثلاث خطوات، لا أكثر:
- الأصول تقبع على خادم التخزين. تُرفع مرة واحدة، ثم يندر أن تُلمس بعد ذلك.
- النسخ المشتقّة تُنشأ مرة واحدة وتبقى على خادم الويب. أي الصور المصغّرة والنسخ المقتطعة والإصدارات المضغوطة. فهي صغيرة، ويُحتاج إليها عند كل استدعاء للصفحة.
- التنزيلات تمر عبر تطبيقكم. سكربت صغير يتحقّق من الصلاحية، ويجلب الملف من خادم التخزين، ويخرجه.
ومن يعكس ذلك ويجلب الصور المصغّرة من خادم التخزين عند كل استدعاء من جديد، يبني لنفسه موقعاً بطيئاً. فزمن المرور في الشبكة يتراكم لكل ملف، ومعرض فيه أربعون صورة ينتظر أربعين مرة.
أي بروتوكول لأي حالة
| البروتوكول | المنفذ | جيد لـ | يحتاج |
|---|---|---|---|
| SMB / CIFS | 445 | التركيب كمجلد | صلاحيات root على الخادم |
| SSHFS | 23 | التركيب كمجلد، مشفّراً | صلاحيات root على الخادم |
| SFTP | 23 | الوصول من PHP والسكربتات وعمليات النقل | المنفذ 23 صادراً |
| WebDAV عبر HTTPS | 443 | الاستضافة المشتركة والبيئات المحدودة | HTTPS فقط |
| rsync | 23 | مزامنة المجلدات الكبيرة | المنفذ 23 صادراً |
| BorgBackup | 23 | النسخ الاحتياطية مع إزالة التكرار | المنفذ 23 صادراً |
القرار الأهم لا يتعلق بالذوق، بل بصلاحياتكم: على خادم خاص بكم تركّبون خادم التخزين كمجلد، فيستطيع كل تطبيق استخدامه دون أن يعرف شيئاً عن ذلك. وكيف يتم ذلك، يشرحه مقال ربط Storage Server كمحرك أقراص شبكة.
وعلى الاستضافة المشتركة لا تملكون صلاحيات root، فيسقط التركيب. وهناك يمر الطريق عبر WebDAV أو SFTP من داخل التطبيق، وغالباً ما يكون WebDAV أقل مقاومة، لأن المنفذ 443 لا يكاد يكون محظوراً أبداً.
إعداد الوصول من PHP
يكفي لـ SFTP مكتبة بلغة PHP خالصة، ولا حاجة إلى أي امتداد على الخادم:
composer require phpseclib/phpseclib:~3.0
use phpseclib3\Net\SFTP;
$sftp = new SFTP('u123456.storage.kernelhost.net', 23);
if (!$sftp->login('u123456-sub1', $passwort)) {
throw new RuntimeException('فشل تسجيل الدخول');
}
// رفع ملف
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);
// قراءة ملف
$inhalt = $sftp->get('/bilder/2026/original.jpg');
وبالنسبة لـ WebDAV يكفي حتى امتداد curl المدمج:
$ch = curl_init('https://u123456.storage.kernelhost.net/bilder/2026/original.jpg');
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_USERPWD => 'u123456-sub1:' . $passwort,
CURLOPT_TIMEOUT => 30,
]);
$inhalt = curl_exec($ch);
curl_close($ch);
يستخدم المثالان حساباً فرعياً، لا الحساب الرئيسي. والسبب في القسم التالي.
لكل غرض حساب فرعي خاص
يسمح كل Storage Server بـ 100 حساب فرعي كحد أقصى، وذلك في كل تعرفة. ويحصل كل حساب على:
- مجلد بداية خاص به لا يستطيع الخروج منه،
- كلمة مرور خاصة به،
- تصاريح بروتوكولات خاصة به، أي SFTP وحده ودون Samba على سبيل المثال.
وبالنسبة لموقع إلكتروني يعني ذلك: حساب فرعي لخادم الويب يُسمح له بـ SFTP وحده ولا يرى غير /web، وحساب ثانٍ للنسخة الاحتياطية لا يرى غير /backup. فإذا اختُرق خادم الويب يوماً، لا يصل المهاجم إلى النسخ الاحتياطية، لأن الحساب لا يعرفها أصلاً.
وهناك حد واحد: لا يحصل الحساب الفرعي على حصة مساحة خاصة به. فهو يبقى في مجلده، لكنه يستطيع أن يملأ هناك مساحة التعرفة كلها. ومن يريد تحديد مستخدمين أفراد فعلاً، يحتاج إلى تطبيق أمامه يتولى ذلك. ويعرض مقال ربط Nextcloud بـ Storage Server هذا البناء بالضبط.
تسليم التنزيلات بشكل آمن
أكثر الأخطاء شيوعاً هو ترك بيانات الدخول تصل إلى المتصفح، مثلاً عبر رابط يحمل اسم المستخدم وكلمة المرور. والصحيح أن يُنشئ خادمكم الاتصال ويمرّر الملف:
<?php
// تحقّقوا من الصلاحية قبل أن يحدث أي شيء
if (!nutzer_darf_datei($_GET['id'])) {
http_response_code(403);
exit;
}
$sftp = neue_verbindung();
$datei = $sftp->get(pfad_zu($_GET['id']));
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="dokument.pdf"');
header('Content-Length: ' . strlen($datei));
echo $datei;
وفي الملفات الكبيرة جداً، الأفضل أن تقرأوا على كتل بدلاً من تحميل كل شيء في الذاكرة، وإلا انقطع العمل عند حد ذاكرة PHP. استخدموا لذلك ob_end_flush() وأخرجوا الملف قطعةً قطعة.
ومن يتوقع تنزيلات كثيرة في وقت واحد، فعليه أن يأخذ في الحساب أن كل تنزيل جارٍ يشغل عملية PHP. وبدءاً من حجم معيّن، يكون موضع ذلك خلف خادم خاص لا خلف استضافة مشتركة.
نسخ الموقع احتياطياً على خادم التخزين
هذه أبسط بداية، وهي تنفع فوراً. فبـ rsync لا تنقلون غير التغييرات:
rsync -az --delete -e "ssh -p 23" \
/var/www/example.com/ \
u123456-sub2@u123456.storage.kernelhost.net:/backup/web/
وللنسخ الاحتياطية مع إزالة التكرار والتشفير يكون BorgBackup الخيار الأفضل، وهو متاح على خادم التخزين بشكل أصلي. ويضاف إلى ذلك لقطات خادم التخزين نفسه كطبقة ثانية: 10 أو 20 أو 30 أو 40 لقطة يدوية بحسب التعرفة، ومثلها عدداً لقطات تلقائية بوتيرة يومية وأسبوعية وشهرية.
والفرق عن النسخ الاحتياطي على الخادم نفسه هو الفرق الحاسم: فالقرص المحذوف أو المشفَّر يأخذ معه النسخة الاحتياطية المحلية، أما النسخة على تخزين منفصل فلا.
قبل أن تبدؤوا: زرّا تبديل
تجدون في منطقة العملاء عند Storage Server الزر «إعدادات الوصول». ويجب أن يكون أمران على ما ينبغي:
- الوصول الخارجي يجب أن يكون مفعّلاً، وإلا لم يصل خادم الويب لديكم إلى خادم التخزين عبر الإنترنت.
- البروتوكول المطلوب يجب أن يكون مسموحاً، أي Samba لـ SMB، وSSH لـ SFTP وrsync، وWebDAV لطريق HTTPS.
وفي الخوادم المطلوبة حديثاً يكون ذلك كله مفعّلاً. ومن يعطّل لأسباب أمنية ما لا يحتاجه، فليتذكّر أن هذا بالضبط هو أكثر الأسباب شيوعاً لاحقاً لعبارة «لم يعد يعمل».
أي تعرفة تناسبكم
| التعرفة | المساحة | الحسابات الفرعية | اللقطات | السعر |
|---|---|---|---|---|
| Storage-1 | 1 TB | 100 | 10 زائد 10 تلقائية | 9.99 EUR |
| Storage-2 | 5 TB | 100 | 20 زائد 20 تلقائية | 29.99 EUR |
| Storage-3 | 10 TB | 100 | 30 زائد 30 تلقائية | 39.99 EUR |
| Storage-4 | 20 TB | 100 | 40 زائد 40 تلقائية | 69.99 EUR |
تقف جميع خوادم Storage Server في ألمانيا، وتتكلم FTP وFTPS وSFTP وSCP وSamba وWebDAV وWebDAVs، وتأتي بـ rsync وBorgBackup بشكل أصلي، ولها IPv4 وIPv6. ولا توجد رسوم إعداد، والمحاسبة على أساس الدفع المسبق دون مدة التزام دنيا. أي أنكم تستطيعون البدء بـ 1 TB والتوسيع لاحقاً دون انتقال.
ومثال حسابي: 1 TB مساحة إضافية على خادم ويب تكلّف أضعاف 9.99 يورو في الشهر بحسب المزوّد، وتقبع عندها على الجهاز نفسه الذي عليه الموقع. أما خادم التخزين المجاور فليس أرخص فقط، بل منفصل أيضاً.
الأسئلة الشائعة
هل يمكنني تضمين الصور في موقعي من Storage Server مباشرةً؟
أي بروتوكول أستخدم من خادم الويب؟
هل يحل Storage Server مكان شبكة CDN؟
كم حساباً فرعياً أستطيع إنشاءه؟
هل أستطيع تخصيص مساحة خاصة لحساب فرعي؟
ما سرعة الوصول؟
هل تكون بيانات الدخول مرئية في المتصفح؟
هل أستطيع أيضاً نسخ موقعي احتياطياً عليه؟
هل أحتاج لذلك إلى خادم خاص؟
ما تكلفة ذلك؟
2026 KernelHost GmbH. جميع الحقوق محفوظة. هذا الشرح محمي بحقوق النشر. لا يُسمح بإعادة نشره على مواقع أخرى، كليًا أو جزئيًا أو بصيغة معدّلة، دون موافقتنا الخطية. أما الاقتباس مع ذكر المصدر ووضع رابط فهو مرحّب به تمامًا.

