النسخ الاحتياطي والاستعادة في ClickHouse

نظرة عامة على النسخ الاحتياطي والاستعادة في ClickHouse

يتناول هذا القسم بصورة عامة النسخ الاحتياطية وعمليات الاستعادة في ClickHouse. للحصول على وصف أكثر تفصيلًا لكل طريقة من طرق النسخ الاحتياطي، راجع الصفحات المخصصة للطرق المختلفة في الشريط الجانبي.

​

المقدمة

في حين أن النسخ المتماثل يوفر حماية من أعطال الأجهزة، فإنه لا يوفر حماية من الأخطاء البشرية: الحذف غير المقصود للبيانات، أو حذف الجدول الخطأ أو جدول في العنقود الخطأ، وأخطاء البرمجيات التي تؤدي إلى معالجة غير صحيحة للبيانات أو تلفها.

في كثير من الحالات، ستؤثر أخطاء كهذه في جميع النسخ المتماثلة. يتضمن ClickHouse وسائل حماية مدمجة لمنع بعض أنواع الأخطاء، فعلى سبيل المثال، افتراضيًا لا يمكنك ببساطة حذف الجداول التي تستخدم محركًا من عائلة MergeTree وتحتوي على أكثر من 50 غيغابايت من البيانات. ومع ذلك، لا تغطي وسائل الحماية هذه جميع الحالات الممكنة، وقد تظل المشكلات واردة.

للحد بفعالية من الأخطاء البشرية المحتملة، ينبغي لك أن تُعد بعناية استراتيجية للنسخ الاحتياطي لبياناتك واستعادتها مسبقًا.

تختلف الموارد المتاحة ومتطلبات الأعمال من شركة إلى أخرى، لذلك لا يوجد حل شامل واحد للنسخ الاحتياطي والاستعادة في ClickHouse يناسب كل الحالات. فما يصلح لغيغابايت واحد من البيانات على الأرجح لن يصلح لعشرات البيتابايتات من البيانات. وهناك مجموعة متنوعة من الأساليب الممكنة، لكل منها مزاياها وعيوبها، وهي معروضة في هذا القسم من الوثائق. ومن الجيد استخدام عدة أساليب بدلًا من الاكتفاء بأسلوب واحد، لتعويض أوجه القصور المختلفة في كل منها.

ضع في اعتبارك أنه إذا أنشأت نسخة احتياطية لشيء ما ولم تحاول استعادته مطلقًا، فمن المحتمل ألا تعمل الاستعادة على النحو الصحيح عندما تحتاج إليها فعلًا (أو على الأقل ستستغرق وقتًا أطول مما يمكن للأعمال تحمله). لذا، أيًّا كانت آلية النسخ الاحتياطي التي تختارها، احرص على أتمتة عملية الاستعادة أيضًا، والتدرّب عليها بانتظام على عنقود ClickHouse احتياطي.

توضح الصفحات التالية بالتفصيل مختلف طرق النسخ الاحتياطي والاستعادة المتاحة في ClickHouse:

الصفحة	الوصف
النسخ الاحتياطي/الاستعادة باستخدام قرص محلي أو S3 disk	يوضح النسخ الاحتياطي/الاستعادة إلى قرص محلي أو S3 disk أو منهما
النسخ الاحتياطي/الاستعادة باستخدام S3 endpoint	يوضح النسخ الاحتياطي/الاستعادة إلى S3 endpoint أو منه
النسخ الاحتياطي/الاستعادة باستخدام AzureBlobStorage	يوضح النسخ الاحتياطي/الاستعادة إلى Azure blob storage أو منه
طرق بديلة	يناقش طرق النسخ الاحتياطي البديلة
Snapshot backup	لقطات خفيفة لجداول SharedMergeTree باستخدام Cloud Object Storage

يمكن للنسخ الاحتياطية أن تكون:

• كاملة أو تزايدية
• متزامنة أو غير متزامنة
• متوازية أو غير متوازية
• مضغوطة أو غير مضغوطة
• تستخدم مجموعات مسمى
• محمية بكلمة مرور
• مأخوذة من جداول النظام أو جداول السجل أو جداول إدارة الوصول

​

أنواع النسخ الاحتياطية

يمكن أن تكون النسخ الاحتياطية إما كاملة أو تزايدية. فالنسخ الاحتياطية الكاملة تكون نسخة كاملة من البيانات، بينما تتضمن النسخ الاحتياطية التزايدية فقط التغييرات التي طرأت على البيانات منذ آخر نسخة احتياطية كاملة.

تمتاز النسخ الاحتياطية الكاملة بأنها وسيلة استرداد بسيطة ومستقلة (عن النسخ الاحتياطية الأخرى) وموثوقة. ومع ذلك، قد يستغرق إكمالها وقتًا طويلًا، وقد تستهلك مساحة كبيرة. أما النسخ الاحتياطية التزايدية، فهي أكثر كفاءة من حيث الوقت والمساحة، لكن استعادة البيانات تتطلب توفر جميع النسخ الاحتياطية.

اعتمادًا على احتياجاتك، قد ترغب في استخدام:

• النسخ الاحتياطية الكاملة لقواعد البيانات الأصغر أو للبيانات المهمة.
• النسخ الاحتياطية التزايدية لقواعد البيانات الأكبر أو عندما تكون هناك حاجة إلى إجراء النسخ الاحتياطية بشكل متكرر وبأقل تكلفة.
• كليهما، مثلًا نسخ احتياطية كاملة أسبوعية ونسخ احتياطية تزايدية يومية.

​

النسخ الاحتياطية المتزامنة مقابل غير المتزامنة

يمكن أيضًا تعليم الأمرين BACKUP وRESTORE بـ ASYNC. في هذه الحالة، يعيد أمر النسخ الاحتياطي النتيجة فورًا، وتعمل عملية النسخ الاحتياطي في الخلفية. إذا لم يُعلَّم الأمران بـ ASYNC، فستكون عملية النسخ الاحتياطي متزامنة، ويبقى الأمر قيد الانتظار حتى يكتمل النسخ الاحتياطي.

​

النسخ الاحتياطية المتوازية وغير المتوازية

يتيح ClickHouse افتراضيًا إجراء النسخ الاحتياطية وعمليات الاستعادة بشكل متوازٍ. وهذا يعني أنه يمكنك بدء عدة عمليات نسخ احتياطي أو استعادة في الوقت نفسه. ومع ذلك، توجد إعدادات على مستوى الخادم تتيح لك تعطيل هذا السلوك. إذا ضبطت هذه الإعدادات على false، فلن يُسمح إلا بتشغيل عملية نسخ احتياطي أو استعادة واحدة فقط على العنقود في كل مرة. ويمكن أن يساعد ذلك في تجنب التنافس على الموارد أو التعارضات المحتملة بين العمليات.

لمنع النسخ الاحتياطي/الاستعادة المتوازيين، يمكنك استخدام هذه الإعدادات على التوالي:

<clickhouse>
    <backups>
        <allow_concurrent_backups>false</allow_concurrent_backups>
        <allow_concurrent_restores>false</allow_concurrent_restores>
    </backups>
</clickhouse>

القيمة الافتراضية لكليهما هي true، لذا يُسمح افتراضيًا بإجراء عمليات النسخ الاحتياطي/الاستعادة المتوازية. عندما تكون هذه الإعدادات false على عنقود، لا يُسمح إلا بتشغيل عملية نسخ احتياطي/استعادة واحدة فقط على عنقود في كل مرة.

​

النسخ الاحتياطية المضغوطة مقابل غير المضغوطة

تدعم النسخ الاحتياطية في ClickHouse الضغط من خلال الإعدادين compression_method وcompression_level.

عند إنشاء نسخة احتياطية، يمكنك تحديد ما يلي:

BACKUP TABLE test.table
  TO Disk('backups', 'filename.zip')
  SETTINGS compression_method='lzma', compression_level=3

​

استخدام المجموعات المسماة

تتيح لك المجموعات المسماة تخزين أزواج المفتاح والقيمة (مثل بيانات اعتماد S3، ونقاط النهاية، والإعدادات) بحيث يمكن إعادة استخدامها في عمليات النسخ الاحتياطي والاستعادة. وهي تساعد على:

• إخفاء بيانات الاعتماد عن المستخدمين الذين لا يملكون امتيازات المسؤول
• تبسيط الأوامر من خلال تخزين التهيئة المعقدة مركزيًا
• الحفاظ على الاتساق عبر العمليات
• تجنب كشف بيانات الاعتماد في سجلات الاستعلام

راجع “المجموعات المسماة” لمزيد من التفاصيل.

​

أخذ نسخ احتياطية من جداول النظام أو السجل أو إدارة الوصول

يمكن أيضًا تضمين جداول النظام في سير عمل النسخ الاحتياطي والاستعادة، لكن يعتمد تضمينها على حالة الاستخدام الخاصة بك.

يمكن أخذ نسخ احتياطية من جداول النظام التي تخزّن بيانات تاريخية، مثل تلك التي تحمل اللاحقة _log (على سبيل المثال، query_log وpart_log)، واستعادتها مثل أي جدول آخر. إذا كانت حالة الاستخدام لديك تعتمد على تحليل البيانات التاريخية - على سبيل المثال، استخدام query_log لتتبّع أداء الاستعلامات أو استكشاف المشكلات وإصلاحها - فمن المستحسن تضمين هذه الجداول في استراتيجية النسخ الاحتياطي. ومع ذلك، إذا لم تكن البيانات التاريخية في هذه الجداول مطلوبة، فيمكن استبعادها لتوفير مساحة تخزين النسخ الاحتياطية.

تخضع جداول النظام المرتبطة بإدارة الوصول، مثل users وroles وrow_policies و settings_profiles وquotas، لمعالجة خاصة أثناء عمليات النسخ الاحتياطي والاستعادة. فعند تضمين هذه الجداول في نسخة احتياطية، يُصدَّر محتواها إلى ملف خاص accessXX.txt، يتضمّن تعليمات SQL المكافئة لإنشاء كيانات الوصول وتهيئتها. وعند الاستعادة، تقوم عملية الاستعادة بتفسير هذه الملفات وإعادة تطبيق أوامر SQL لإعادة إنشاء المستخدمين، والأدوار، والتهيئات الأخرى. وتضمن هذه الميزة إمكانية أخذ نسخة احتياطية من تهيئة التحكم في الوصول في عنقود ClickHouse واستعادتها كجزء من الإعداد العام للعنقود.

لا تعمل هذه الوظيفة إلا مع التهيئات المُدارة من خلال أوامر SQL (ويُشار إليها باسم “إدارة التحكم في الوصول والحسابات المعتمدة على SQL”). أما تهيئات الوصول المعرّفة في ملفات تهيئة خادم ClickHouse (مثل users.xml) فلا تُضمَّن في النسخ الاحتياطية ولا يمكن استعادتها بهذه الطريقة.

​

البنية العامة

-- 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('<path>/<filename>') | 
Disk('<disk_name>', '<path>/') | 
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>', '<extra_credentials>') |
AzureBlobStorage('<connection string>/<url>', '<container>', '<path>', '<account name>', '<account key>')
--- additional settings
[SETTINGS ...]
[ASYNC]

راجع “ملخص الأوامر” لمزيد من التفاصيل عن كل أمر.

​

ملخص الأوامر

يُفصَّل أدناه كل أمر من الأوامر المذكورة أعلاه:

الأمر	الوصف
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('<path>/<filename>')	يخزّن في نظام الملفات المحلي أو يستعيد منه
Disk('<disk_name>', '<path>/')	يخزّن على قرص مُهيّأ أو يستعيد منه
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>')	يخزّن في Amazon S3 أو وحدة تخزين متوافقة مع S3، أو يستعيد منها
[SETTINGS ...]	انظر أدناه للاطلاع على القائمة الكاملة للإعدادات
[ASYNC]	يجعل العملية تعمل بشكل غير متزامن (وتُرجع فورًا معرّفًا يمكنك مراقبته)

​

الإعدادات

إعدادات النسخ الاحتياطي والاستعادة العامة

الإعداد	الوصف	القيمة الافتراضية
id	معرّف عملية النسخ الاحتياطي أو الاستعادة. إذا لم يُحدَّد، فسيُستخدَم UUID مُولَّد عشوائيًا. وإذا كانت هناك عملية قيد التشغيل بالفعل بالمعرّف نفسه، فسيتم إطلاق استثناء.
compression_method	يحدّد أسلوب الضغط للنسخة الاحتياطية. راجع قسم “مرمّزات ضغط الأعمدة”
compression_level	يحدّد مستوى الضغط للنسخة الاحتياطية
password	كلمة مرور أرشيف النسخة الاحتياطية. لا يُدعم ذلك إلا لأرشيفات ZIP (.zip, .zipx).
base_backup	وجهة النسخة الاحتياطية الأساسية المستخدَمة للنسخ الاحتياطية التزايدية. مثال: Disk('backups', '1.zip')
use_same_password_for_base_backup	ما إذا كان ينبغي أن يرث أرشيف النسخة الاحتياطية الأساسية كلمة المرور من الاستعلام.
structure_only	إذا كان مُمكّنًا، فسيتم فقط إجراء نسخ احتياطي لعبارات CREATE أو استعادتها من دون بيانات الجدول الفعلية.
storage_policy	سياسة التخزين للجداول التي تتم استعادتها. راجع “استخدام عدة أجهزة تخزين كتلية لتخزين البيانات. ينطبق هذا فقط على الأمر 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 الطويلة. يوضّح المثال أدناه فشلًا حدث عند محاولة استبدال ملف نسخ احتياطي موجود:

BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC

┌─id───────────────────────────────────┬─status──────────┐
│ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │
└──────────────────────────────────────┴─────────────────┘

1 row in set. Elapsed: 0.001 sec.

SELECT
*
FROM system.backups
WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52'
FORMAT Vertical

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، تُسجَّل أيضًا جميع عمليات النسخ الاحتياطي والاستعادة في جدول سجل النظام system.backup_log:

SELECT *
FROM system.backup_log
WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52'
ORDER BY event_time_microseconds ASC
FORMAT Vertical

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.