> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > نظرة عامة على النسخ الاحتياطي والاستعادة في ClickHouse # النسخ الاحتياطي والاستعادة في ClickHouse > يتناول هذا القسم بصورة عامة النسخ الاحتياطية وعمليات الاستعادة في ClickHouse. للحصول على > وصف أكثر تفصيلًا لكل طريقة من طرق النسخ الاحتياطي، راجع الصفحات المخصصة للطرق المختلفة > في الشريط الجانبي.
## المقدمة
في حين أن [النسخ المتماثل](/ar/reference/engines/table-engines/mergetree-family/replication) يوفر حماية من أعطال الأجهزة، فإنه لا يوفر حماية من الأخطاء البشرية: الحذف غير المقصود للبيانات، أو حذف الجدول الخطأ أو جدول في العنقود الخطأ، وأخطاء البرمجيات التي تؤدي إلى معالجة غير صحيحة للبيانات أو تلفها. في كثير من الحالات، ستؤثر أخطاء كهذه في جميع النسخ المتماثلة. يتضمن ClickHouse وسائل حماية مدمجة لمنع بعض أنواع الأخطاء، فعلى سبيل المثال، [افتراضيًا](/ar/reference/settings/session-settings#max_table_size_to_drop) لا يمكنك ببساطة حذف الجداول التي تستخدم محركًا من عائلة `MergeTree` وتحتوي على أكثر من 50 غيغابايت من البيانات. ومع ذلك، لا تغطي وسائل الحماية هذه جميع الحالات الممكنة، وقد تظل المشكلات واردة. للحد بفعالية من الأخطاء البشرية المحتملة، ينبغي لك أن تُعد بعناية استراتيجية للنسخ الاحتياطي لبياناتك واستعادتها **مسبقًا**. تختلف الموارد المتاحة ومتطلبات الأعمال من شركة إلى أخرى، لذلك لا يوجد حل شامل واحد للنسخ الاحتياطي والاستعادة في ClickHouse يناسب كل الحالات. فما يصلح لغيغابايت واحد من البيانات على الأرجح لن يصلح لعشرات البيتابايتات من البيانات. وهناك مجموعة متنوعة من الأساليب الممكنة، لكل منها مزاياها وعيوبها، وهي معروضة في هذا القسم من الوثائق. ومن الجيد استخدام عدة أساليب بدلًا من الاكتفاء بأسلوب واحد، لتعويض أوجه القصور المختلفة في كل منها. ضع في اعتبارك أنه إذا أنشأت نسخة احتياطية لشيء ما ولم تحاول استعادته مطلقًا، فمن المحتمل ألا تعمل الاستعادة على النحو الصحيح عندما تحتاج إليها فعلًا (أو على الأقل ستستغرق وقتًا أطول مما يمكن للأعمال تحمله). لذا، أيًّا كانت آلية النسخ الاحتياطي التي تختارها، احرص على أتمتة عملية الاستعادة أيضًا، والتدرّب عليها بانتظام على عنقود ClickHouse احتياطي. توضح الصفحات التالية بالتفصيل مختلف طرق النسخ الاحتياطي والاستعادة المتاحة في ClickHouse: | الصفحة | الوصف | | -------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | [النسخ الاحتياطي/الاستعادة باستخدام قرص محلي أو S3 disk](/ar/concepts/features/backup-restore/local-disk) | يوضح النسخ الاحتياطي/الاستعادة إلى قرص محلي أو S3 disk أو منهما | | [النسخ الاحتياطي/الاستعادة باستخدام S3 endpoint](/ar/concepts/features/backup-restore/s3-endpoint) | يوضح النسخ الاحتياطي/الاستعادة إلى S3 endpoint أو منه | | [النسخ الاحتياطي/الاستعادة باستخدام AzureBlobStorage](/ar/concepts/features/backup-restore/azure-blob-storage) | يوضح النسخ الاحتياطي/الاستعادة إلى Azure blob storage أو منه | | [طرق بديلة](/ar/concepts/features/backup-restore/alternative-methods) | يناقش طرق النسخ الاحتياطي البديلة | | [Snapshot backup](/ar/concepts/features/backup-restore/snapshot) | لقطات خفيفة لجداول SharedMergeTree باستخدام Cloud Object Storage | يمكن للنسخ الاحتياطية أن تكون: * [كاملة أو تزايدية](#backup-types) * [متزامنة أو غير متزامنة](#synchronous-vs-asynchronous) * [متوازية أو غير متوازية](#concurrent-vs-non-concurrent) * [مضغوطة أو غير مضغوطة](#compressed-vs-uncompressed) * تستخدم [مجموعات مسمى](#using-named-collections) * محمية بكلمة مرور * مأخوذة من [جداول النظام أو جداول السجل أو جداول إدارة الوصول](#system-backups)
## أنواع النسخ الاحتياطية
يمكن أن تكون النسخ الاحتياطية إما كاملة أو تزايدية. فالنسخ الاحتياطية الكاملة تكون نسخة كاملة من البيانات، بينما تتضمن النسخ الاحتياطية التزايدية فقط التغييرات التي طرأت على البيانات منذ آخر نسخة احتياطية كاملة. تمتاز النسخ الاحتياطية الكاملة بأنها وسيلة استرداد بسيطة ومستقلة (عن النسخ الاحتياطية الأخرى) وموثوقة. ومع ذلك، قد يستغرق إكمالها وقتًا طويلًا، وقد تستهلك مساحة كبيرة. أما النسخ الاحتياطية التزايدية، فهي أكثر كفاءة من حيث الوقت والمساحة، لكن استعادة البيانات تتطلب توفر جميع النسخ الاحتياطية. اعتمادًا على احتياجاتك، قد ترغب في استخدام: * **النسخ الاحتياطية الكاملة** لقواعد البيانات الأصغر أو للبيانات المهمة. * **النسخ الاحتياطية التزايدية** لقواعد البيانات الأكبر أو عندما تكون هناك حاجة إلى إجراء النسخ الاحتياطية بشكل متكرر وبأقل تكلفة. * **كليهما**، مثلًا نسخ احتياطية كاملة أسبوعية ونسخ احتياطية تزايدية يومية.
## النسخ الاحتياطية المتزامنة مقابل غير المتزامنة
يمكن أيضًا تعليم الأمرين `BACKUP` و`RESTORE` بـ `ASYNC`. في هذه الحالة، يعيد أمر النسخ الاحتياطي النتيجة فورًا، وتعمل عملية النسخ الاحتياطي في الخلفية. إذا لم يُعلَّم الأمران بـ `ASYNC`، فستكون عملية النسخ الاحتياطي متزامنة، ويبقى الأمر قيد الانتظار حتى يكتمل النسخ الاحتياطي.
## النسخ الاحتياطية المتوازية وغير المتوازية
يتيح ClickHouse افتراضيًا إجراء النسخ الاحتياطية وعمليات الاستعادة بشكل متوازٍ. وهذا يعني أنه يمكنك بدء عدة عمليات نسخ احتياطي أو استعادة في الوقت نفسه. ومع ذلك، توجد إعدادات على مستوى الخادم تتيح لك تعطيل هذا السلوك. إذا ضبطت هذه الإعدادات على false، فلن يُسمح إلا بتشغيل عملية نسخ احتياطي أو استعادة واحدة فقط على العنقود في كل مرة. ويمكن أن يساعد ذلك في تجنب التنافس على الموارد أو التعارضات المحتملة بين العمليات. لمنع النسخ الاحتياطي/الاستعادة المتوازيين، يمكنك استخدام هذه الإعدادات على التوالي: ```xml theme={null} false false ``` القيمة الافتراضية لكليهما هي true، لذا يُسمح افتراضيًا بإجراء عمليات النسخ الاحتياطي/الاستعادة المتوازية. عندما تكون هذه الإعدادات false على عنقود، لا يُسمح إلا بتشغيل عملية نسخ احتياطي/استعادة واحدة فقط على عنقود في كل مرة.
## النسخ الاحتياطية المضغوطة مقابل غير المضغوطة
تدعم النسخ الاحتياطية في ClickHouse الضغط من خلال الإعدادين `compression_method` و`compression_level`. عند إنشاء نسخة احتياطية، يمكنك تحديد ما يلي: ```sql theme={null} BACKUP TABLE test.table TO Disk('backups', 'filename.zip') SETTINGS compression_method='lzma', compression_level=3 ```
## استخدام المجموعات المسماة
تتيح لك المجموعات المسماة تخزين أزواج المفتاح والقيمة (مثل بيانات اعتماد S3، ونقاط النهاية، والإعدادات) بحيث يمكن إعادة استخدامها في عمليات النسخ الاحتياطي والاستعادة. وهي تساعد على: * إخفاء بيانات الاعتماد عن المستخدمين الذين لا يملكون امتيازات المسؤول * تبسيط الأوامر من خلال تخزين التهيئة المعقدة مركزيًا * الحفاظ على الاتساق عبر العمليات * تجنب كشف بيانات الاعتماد في سجلات الاستعلام راجع ["المجموعات المسماة"](/ar/concepts/features/configuration/server-config/named-collections) لمزيد من التفاصيل.
## أخذ نسخ احتياطية من جداول النظام أو السجل أو إدارة الوصول
يمكن أيضًا تضمين جداول النظام في سير عمل النسخ الاحتياطي والاستعادة، لكن يعتمد تضمينها على حالة الاستخدام الخاصة بك. يمكن أخذ نسخ احتياطية من جداول النظام التي تخزّن بيانات تاريخية، مثل تلك التي تحمل اللاحقة `_log` (على سبيل المثال، `query_log` و`part_log`)، واستعادتها مثل أي جدول آخر. إذا كانت حالة الاستخدام لديك تعتمد على تحليل البيانات التاريخية - على سبيل المثال، استخدام `query_log` لتتبّع أداء الاستعلامات أو استكشاف المشكلات وإصلاحها - فمن المستحسن تضمين هذه الجداول في استراتيجية النسخ الاحتياطي. ومع ذلك، إذا لم تكن البيانات التاريخية في هذه الجداول مطلوبة، فيمكن استبعادها لتوفير مساحة تخزين النسخ الاحتياطية. تخضع جداول النظام المرتبطة بإدارة الوصول، مثل users وroles وrow\_policies و settings\_profiles وquotas، لمعالجة خاصة أثناء عمليات النسخ الاحتياطي والاستعادة. فعند تضمين هذه الجداول في نسخة احتياطية، يُصدَّر محتواها إلى ملف خاص `accessXX.txt`، يتضمّن تعليمات SQL المكافئة لإنشاء كيانات الوصول وتهيئتها. وعند الاستعادة، تقوم عملية الاستعادة بتفسير هذه الملفات وإعادة تطبيق أوامر SQL لإعادة إنشاء المستخدمين، والأدوار، والتهيئات الأخرى. وتضمن هذه الميزة إمكانية أخذ نسخة احتياطية من تهيئة التحكم في الوصول في عنقود ClickHouse واستعادتها كجزء من الإعداد العام للعنقود. لا تعمل هذه الوظيفة إلا مع التهيئات المُدارة من خلال أوامر SQL (ويُشار إليها باسم ["إدارة التحكم في الوصول والحسابات المعتمدة على SQL"](/ar/concepts/features/security/access-rights#enabling-access-control)). أما تهيئات الوصول المعرّفة في ملفات تهيئة خادم ClickHouse (مثل `users.xml`) فلا تُضمَّن في النسخ الاحتياطية ولا يمكن استعادتها بهذه الطريقة.
## البنية العامة
```sql theme={null} -- core commands BACKUP | RESTORE --- what to backup/restore (or exclude) TABLE [db.]table_name [AS [db.]table_name_in_backup] | DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] | DATABASE database_name [AS database_name_in_backup] | TEMPORARY TABLE table_name [AS table_name_in_backup] | VIEW view_name [AS view_name_in_backup] | [EXCEPT TABLES ...] | ALL [EXCEPT {TABLES|DATABASES}...] } [,...] --- [ON CLUSTER 'cluster_name'] --- where to backup or restore to or from TO|FROM File('/') | Disk('', '/') | S3('/', '', '', '') | AzureBlobStorage('/', '', '', '', '') --- additional settings [SETTINGS ...] [ASYNC] ``` **راجع ["ملخص الأوامر"](/ar/concepts/features/backup-restore/overview#command-summary) لمزيد من التفاصيل عن كل أمر.**
### ملخص الأوامر
يُفصَّل أدناه كل أمر من الأوامر المذكورة أعلاه: | **الأمر** | **الوصف** | | | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | | `BACKUP` | يُنشئ نسخة احتياطية للكائنات المحددة | | | `RESTORE` | يستعيد الكائنات من نسخة احتياطية | | | `TABLE [db.]table_name [AS [db.]table_name_in_backup]` | يُنشئ نسخة احتياطية لجدول محدد أو يستعيده (مع إمكانية إعادة تسميته) | | | `[PARTITION[S] partition_expr [,...]]` | يُنشئ نسخة احتياطية لأقسام محددة من الجدول أو يستعيدها فقط | | | `DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup]` | يُنشئ نسخة احتياطية لكائن قاموس أو يستعيده | | | `DATABASE database_name [AS database_name_in_backup]` | يُنشئ نسخة احتياطية لقاعدة بيانات كاملة أو يستعيدها (مع إمكانية إعادة تسميتها) | | | `TEMPORARY TABLE table_name [AS table_name_in_backup]` | يُنشئ نسخة احتياطية لجدول مؤقت أو يستعيده (مع إمكانية إعادة تسميته) | | | `VIEW view_name [AS view_name_in_backup]` | يُنشئ نسخة احتياطية لطريقة عرض أو يستعيدها (مع إمكانية إعادة تسميتها) | | | `[EXCEPT TABLES ...]` | يستبعد جداول محددة عند إنشاء نسخة احتياطية لقاعدة بيانات | | | `ALL` | يُنشئ نسخة احتياطية لكل شيء أو يستعيده (جميع قواعد البيانات والجداول وما إلى ذلك). قبل الإصدار 23.4 من ClickHouse، كان `ALL` قابلاً للتطبيق فقط على الأمر `RESTORE`. | | | `[EXCEPT {TABLES\|DATABASES}...]` | يستبعد جداول أو قواعد بيانات محددة عند استخدام `ALL` | | | `[ON CLUSTER 'cluster_name']` | ينفّذ النسخ الاحتياطي أو الاستعادة على مستوى عنقود ClickHouse | | | `TO\|FROM` | الاتجاه: `TO` لوجهة النسخ الاحتياطي، و`FROM` لمصدر الاستعادة | | | `File('/')` | يخزّن في نظام الملفات المحلي أو يستعيد منه | | | `Disk('', '/')` | يخزّن على قرص مُهيّأ أو يستعيد منه | | | `S3('/', '', '')` | يخزّن في Amazon S3 أو وحدة تخزين متوافقة مع S3، أو يستعيد منها | | | `[SETTINGS ...]` | انظر أدناه للاطلاع على القائمة الكاملة للإعدادات | | | `[ASYNC]` | يجعل العملية تعمل بشكل غير متزامن (وتُرجع فورًا معرّفًا يمكنك مراقبته) | |
### الإعدادات
**إعدادات النسخ الاحتياطي والاستعادة العامة** | الإعداد | الوصف | القيمة الافتراضية | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | | `id` | معرّف عملية النسخ الاحتياطي أو الاستعادة. إذا لم يُحدَّد، فسيُستخدَم UUID مُولَّد عشوائيًا. وإذا كانت هناك عملية قيد التشغيل بالفعل بالمعرّف نفسه، فسيتم إطلاق استثناء. | | | `compression_method` | يحدّد أسلوب الضغط للنسخة الاحتياطية. راجع قسم ["مرمّزات ضغط الأعمدة"](/ar/reference/statements/create/table#column_compression_codec) | | | `compression_level` | يحدّد مستوى الضغط للنسخة الاحتياطية | | | `password` | كلمة مرور أرشيف النسخة الاحتياطية. لا يُدعم ذلك إلا لأرشيفات ZIP (`.zip`, `.zipx`). | | | `base_backup` | وجهة النسخة الاحتياطية الأساسية المستخدَمة للنسخ الاحتياطية التزايدية. مثال: `Disk('backups', '1.zip')` | | | `use_same_password_for_base_backup` | ما إذا كان ينبغي أن يرث أرشيف النسخة الاحتياطية الأساسية كلمة المرور من الاستعلام. | | | `structure_only` | إذا كان مُمكّنًا، فسيتم فقط إجراء نسخ احتياطي لعبارات CREATE أو استعادتها من دون بيانات الجدول الفعلية. | | | `storage_policy` | سياسة التخزين للجداول التي تتم استعادتها. راجع ["استخدام عدة أجهزة تخزين كتلية لتخزين البيانات](/ar/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-multiple-volumes). ينطبق هذا فقط على الأمر `RESTORE`. ولا يسري إلا على الجداول التي تستخدم محركًا من عائلة `MergeTree`. | | | `allow_non_empty_tables` | يسمح `RESTORE TABLE` بإدراج البيانات في الجداول غير الفارغة. سيؤدي ذلك إلى دمج البيانات الموجودة مسبقًا في الجدول مع البيانات المستخرجة من النسخة الاحتياطية. لذلك قد يتسبب هذا الإعداد في تكرار البيانات داخل الجدول، لذا استخدمه بحذر. | `0` | | `backup_restore_keeper_max_retries` | الحد الأقصى لعدد إعادة المحاولة لعمليات \[Zoo]Keeper أثناء تنفيذ عملية BACKUP أو RESTORE. يجب أن يكون كبيرًا بما يكفي حتى لا تفشل العملية بأكملها بسبب عطل مؤقت في \[Zoo]Keeper. | `1000` | | `backup_restore_keeper_retry_initial_backoff_ms` | مهلة التراجع الأولية لعمليات \[Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | `100` | | `backup_restore_keeper_retry_max_backoff_ms` | الحد الأقصى لمهلة التراجع لعمليات \[Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | `5000` | | `backup_restore_failure_after_host_disconnected_for_seconds` | إذا لم يُعِد أي مضيف أثناء عملية `BACKUP ON CLUSTER` أو `RESTORE ON CLUSTER` إنشاء عقدة `ephemeral` الخاصة به المسماة 'alive' في ZooKeeper خلال هذه المدة، فستُعتبر عملية النسخ الاحتياطي أو الاستعادة بأكملها فاشلة. يجب أن تكون هذه القيمة أكبر من أي مدة معقولة قد يحتاجها المضيف لإعادة الاتصال بـ ZooKeeper بعد حدوث عطل. ويعني الصفر عدم وجود حد. | `3600` | | `backup_restore_keeper_max_retries_while_initializing` | الحد الأقصى لعدد مرات إعادة المحاولة لعمليات \[Zoo]Keeper أثناء تهيئة عملية `BACKUP ON CLUSTER` أو `RESTORE ON CLUSTER`. | `20` | | `backup_restore_keeper_max_retries_while_handling_error` | الحد الأقصى لعدد مرات إعادة المحاولة لعمليات \[Zoo]Keeper عند التعامل مع خطأ في عملية `BACKUP ON CLUSTER` أو `RESTORE ON CLUSTER`. | `20` | | `backup_restore_finish_timeout_after_error_sec` | المدة التي ينبغي أن تنتظرها العقدة البادئة حتى تستجيب العُقد الأخرى لعقدة 'الخطأ' وتتوقف عن العمل على عملية `BACKUP ON CLUSTER` أو `RESTORE ON CLUSTER` الحالية. | `180` | | `backup_restore_keeper_value_max_size` | الحد الأقصى لحجم بيانات عقدة \[Zoo]Keeper أثناء النسخ الاحتياطي | `1048576` | | `backup_restore_batch_size_for_keeper_multi` | الحد الأقصى لحجم الدفعة للطلب المتعدد إلى \[Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | `1000` | | `backup_restore_batch_size_for_keeper_multiread` | الحد الأقصى لحجم الدفعة لطلب القراءة المتعددة إلى \[Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | `10000` | | `backup_restore_keeper_fault_injection_probability` | الاحتمال التقريبي لفشل طلب إلى Keeper أثناء النسخ الاحتياطي أو الاستعادة. يجب أن تكون القيمة ضمن النطاق `[0.0f, 1.0f]` | `0` | | `backup_restore_keeper_fault_injection_seed` | `0` لاستخدام بذرة عشوائية، وإلا فتُستخدم قيمة الإعداد | `0` | | `backup_restore_s3_retry_attempts` | إعداد لـ Aws::Client::RetryStrategy؛ إذ يُجري Aws::Client محاولات إعادة بنفسه، وتعني القيمة 0 عدم إجراء أي محاولات إعادة. ينطبق ذلك فقط على النسخ الاحتياطي/الاستعادة. | `1000` | | `max_backup_bandwidth` | الحد الأقصى لسرعة القراءة، بالبايت في الثانية، لنسخة احتياطية معيّنة على الخادم. وتعني القيمة صفر عدم وجود حد. | `0` | | `max_backups_io_thread_pool_size` | يستخدم ClickHouse خيوط التنفيذ من مجموعة خيوط الإدخال/الإخراج الخاصة بالنسخ الاحتياطية لتنفيذ عمليات الإدخال/الإخراج لنسخ S3 الاحتياطية. ويحدّد `max_backups_io_thread_pool_size` الحد الأقصى لعدد خيوط التنفيذ في المجموعة. | `1000` | | `max_backups_io_thread_pool_free_size` | إذا تجاوز عدد مؤشرات الترابط **الخاملة** في مجمع مؤشرات ترابط الإدخال/الإخراج للنسخ الاحتياطية القيمة `max_backup_io_thread_pool_free_size`، فسيحرر ClickHouse الموارد التي تشغلها مؤشرات الترابط في حالة الخمول ويقلّص حجم المجمع. ويمكن إنشاء مؤشرات الترابط مرة أخرى عند الحاجة. | `0` | | `backups_io_thread_pool_queue_size` | الحد الأقصى لعدد المهام التي يمكن جدولتها على تجمّع مؤشرات ترابط الإدخال/الإخراج الخاص بالنسخ الاحتياطية. يُنصح بالإبقاء على قائمة الانتظار هذه غير محدودة بسبب المنطق الحالي للنسخ الاحتياطي في S3. ملاحظة: تعني القيمة `0` (الافتراضية) أنها غير محدودة. | `0` | | `backup_threads` | الحد الأقصى لعدد الخيوط لتنفيذ طلبات `BACKUP`. | | | `max_backup_bandwidth_for_server` | الحد الأقصى لسرعة القراءة، بالبايت في الثانية، لجميع النسخ الاحتياطية على الخادم. تعني القيمة صفر عدم وجود حد. | `0` | | `shutdown_wait_backups_and_restores` | إذا ضُبطت القيمة على true، فسوف ينتظر ClickHouse اكتمال النسخ الاحتياطية وعمليات الاستعادة الجارية قبل إيقاف التشغيل. | `1` | **إعدادات خاصة بـ S3** | الإعداد | الوصف | القيمة الافتراضية | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------- | | `use_same_s3_credentials_for_base_backup` | ما إذا كان يجب أن ترث النسخة الاحتياطية الأساسية إلى S3 بيانات الاعتماد من الاستعلام. يعمل فقط مع `S3`. | | | `s3_storage_class` | فئة التخزين المستخدمة للنسخ الاحتياطي على S3. على سبيل المثال: `STANDARD` | | **إعدادات خاصة بـ Azure** | الإعداد | الوصف | القيمة الافتراضية | | | | ----------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------- | - | - | | `azure_attempt_to_create_container` | عند استخدام Azure Blob Storage، ما إذا كانت ستتم محاولة إنشاء الحاوية المحددة إذا لم تكن موجودة. | `true` | | |
## الإدارة واستكشاف الأخطاء وإصلاحها
يعيد أمر النسخ الاحتياطي `id` و`status`، ويمكن استخدام هذا الـ`id` للحصول على حالة النسخ الاحتياطي. ويُعد هذا مفيدًا جدًا للتحقق من تقدّم عمليات النسخ الاحتياطي `ASYNC` الطويلة. يوضّح المثال أدناه فشلًا حدث عند محاولة استبدال ملف نسخ احتياطي موجود: ```sql theme={null} BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC ``` ```response theme={null} ┌─id───────────────────────────────────┬─status──────────┐ │ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │ └──────────────────────────────────────┴─────────────────┘ 1 row in set. Elapsed: 0.001 sec. ``` ```sql theme={null} SELECT * FROM system.backups WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52' FORMAT Vertical ``` ```response highlight={5,9} theme={null} Row 1: ────── id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52 name: Disk('backups', '1.zip') status: BACKUP_FAILED num_files: 0 uncompressed_size: 0 compressed_size: 0 error: Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 22.8.2.11 (official build)) start_time: 2022-08-30 09:21:46 end_time: 2022-08-30 09:21:46 1 row in set. Elapsed: 0.002 sec. ``` إلى جانب جدول [`system.backups`](/ar/reference/system-tables/backups)، تُسجَّل أيضًا جميع عمليات النسخ الاحتياطي والاستعادة في جدول سجل النظام [`system.backup_log`](/ar/reference/system-tables/backup_log): ```sql theme={null} SELECT * FROM system.backup_log WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52' ORDER BY event_time_microseconds ASC FORMAT Vertical ``` ```response highlight={26} theme={null} Row 1: ────── event_date: 2023-08-18 event_time_microseconds: 2023-08-18 11:13:43.097414 id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52 name: Disk('backups', '1.zip') status: CREATING_BACKUP error: start_time: 2023-08-18 11:13:43 end_time: 1970-01-01 03:00:00 num_files: 0 total_size: 0 num_entries: 0 uncompressed_size: 0 compressed_size: 0 files_read: 0 bytes_read: 0 Row 2: ────── event_date: 2023-08-18 event_time_microseconds: 2023-08-18 11:13:43.174782 id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52 name: Disk('backups', '1.zip') status: BACKUP_FAILED error: Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 23.8.1.1) start_time: 2023-08-18 11:13:43 end_time: 2023-08-18 11:13:43 num_files: 0 total_size: 0 num_entries: 0 uncompressed_size: 0 compressed_size: 0 files_read: 0 bytes_read: 0 2 rows in set. Elapsed: 0.075 sec. ```