پشتیبان گیری کنید و Gitlab را بازیابی کنید

GitLab وظایف Rake را برای تهیه نسخه پشتیبان و بازیابی نمونه های GitLab فراهم می کند.

پشتیبان گیری داده های برنامه یک فایل بایگانی را ایجاد می کند که حاوی پایگاه داده ، کلیه مخازن و همه پیوست ها باشد.

شما فقط می توانید یک نسخه پشتیبان تهیه کنید و دقیقاً به همان نسخه و نوع (CE/EE) GitLab که در آن ایجاد شده است ، بازیابی کنید. بهترین راه برای انتقال پروژه های خود از یک سرور به سرور دیگر از طریق پشتیبان گیری و بازیابی است.

GitLab از مواردی که در سیستم فایل ذخیره نشده اند پشتیبان تهیه نمی کند. اگر از ذخیره سازی شی استفاده می کنید ، در صورت تمایل حتماً با ارائه دهنده ذخیره سازی شیء خود ، نسخه پشتیبان تهیه کنید.

الزامات

• با استفاده از بسته Omnibus ، RSYNC از قبل نصب شده است.

از منبع ، بررسی کنید که آیا RSYNC نصب شده است یا خیر. اگر RSYNC نصب نشده است ، آن را نصب کنید. مثلا:

بازگردانی Gitaly برای تهیه نسخه پشتیبان از مخزن و بازیابی

• معرفی شده در Gitlab 14. 2.
• در پشت یک پرچم ویژگی مستقر شده است که به طور پیش فرض فعال شده است.
• به طور کلی در Gitlab 14. 10 موجود است. ویژگی پرچم Gitaly_backup حذف شده است.

باینری Gitaly-Backup توسط کار پشتیبان تهیه شده برای ایجاد و بازیابی پشتیبان مخزن از Gitaly استفاده می شود. Gitaly-Backup جایگزین روش پشتیبان گیری قبلی است که مستقیماً RPC ها را از Gitaly از Gitlab فراخوانی می کند.

موارد زیر را به /etc/gitlab/gitlab. rb اضافه کنید:

جدول زمانی پشتیبان

بایگانی پشتیبان در backup_path ذخیره می شود ، که در پرونده config/gitlab. yml مشخص شده است. نام پرونده [Timestamp] _gitlab_backup. tar است ، جایی که Timestamp زمان ایجاد هر نسخه پشتیبان را مشخص می کند ، به علاوه نسخه GITLAB. در صورت نیاز به بازگرداندن GitLab و چندین نسخه پشتیبان تهیه شده در دسترس است.

به عنوان مثال ، اگر نام پشتیبان 1493107454_2018_04_25_10. 6. 4-CE_GITLAB_BACKUP. TAR باشد ، Timestamp 1493107454_2018_04_25_10. 6. 6. 4-CE است.

پشتیبان گیری از Gitlab

برای اطلاعات دقیق در مورد تهیه نسخه پشتیبان از GitLab ، به نسخه پشتیبان تهیه کنید.

Gitlab را بازیابی کنید

برای اطلاعات دقیق در مورد بازیابی GitLab ، به بازیابی Gitlab مراجعه کنید.

استراتژی های جایگزین پشتیبان

• نمونه GitLab شما حاوی داده های مخزن GIT زیادی است و اسکریپت پشتیبان GitLab خیلی کند است.
• نمونه GitLab شما پروژه های چنگال زیادی دارد و وظیفه پشتیبان گیری منظم داده های GIT را برای همه آنها کپی می کند.
• نمونه GitLab شما یک مشکل دارد و استفاده از کارهای پشتیبان و واردات به طور منظم امکان پذیر نیست.

• از این روش ها برای مهاجرت از یک سیستم عامل به دیگری استفاده نکنید. سیستم عامل های منبع و مقصد باید تا حد ممکن مشابه باشد. به عنوان مثال ، از این روش ها برای مهاجرت از اوبونتو به فدورا استفاده نکنید.
• قوام داده ها بسیار مهم است. توصیه می کنیم قبل از انجام انتقال سیستم فایل (به عنوان مثال با RSYNC) یا گرفتن عکس فوری ، GitLab را با Sudo Gitlab-CTL متوقف کنید.

مثال: فروشگاه بلوک الاستیک آمازون (EBS)

یک سرور GitLab با استفاده از Omnibus gitlab میزبان در Amazon AWS. یک درایو EBS حاوی یک سیستم فایل EXT4 در/var/opt/gitlab نصب شده است. در این حالت می توانید با گرفتن عکس فوری EBS ، یک نسخه پشتیبان تهیه کنید. نسخه پشتیبان شامل کلیه مخازن ، آپلودها و داده های postgreSQL است.

مثال: Snapshots (LVM) مدیر حجم منطقی + RSYNC

یک سرور gitlab با استفاده از Omnibus gitlab ، با حجم منطقی LVM در/var/opt/gitlab نصب شده است. تکرار دایرکتوری/var/opt/gitlab با استفاده از RSYNC قابل اعتماد نخواهد بود زیرا در حالی که RSYNC در حال اجرا است ، پرونده های زیادی تغییر می کنند. به جای RSYN C-ING/VAR/OPT/GITLAB ، ما یک عکس فوری موقت LVM ایجاد می کنیم ، که ما به عنوان یک سیستم فایل فقط خواندنی در/mnt/gitlab_backup سوار می شویم. اکنون می توانیم یک کار RSYNC در حال اجرا طولانی تر داشته باشیم که یک ماکت مداوم را در سرور از راه دور ایجاد می کند. این ماکت شامل کلیه مخازن ، آپلودها و داده های postgreSQL است.

اگر GITLAB را روی یک سرور مجازی اجرا می کنید ، می توانید عکس های VM از کل سرور GitLab نیز ایجاد کنید. با این وجود غیر معمول نیست که یک عکس فوری VM شما را ملزم به پایین آمدن سرور کند ، که استفاده عملی این راه حل را محدود می کند.

از داده های مخزن جداگانه پشتیبان تهیه کنید

ابتدا اطمینان حاصل کنید که از داده های موجود GitLab در هنگام پرش از مخازن پشتیبان تهیه می کنید:

• از عکسهای فوری مانند نمونه های قبلی آمازون EBS عکس های فوری یا عکس های LVM + RSYNC استفاده کنید.
• از Gitlab Geo استفاده کنید و به داده های مخزن در یک سایت ثانویه GEO اعتماد کنید.
• از نوشتن و کپی کردن داده های مخزن GIT جلوگیری کنید.
• با علامت گذاری مخازن به عنوان فقط خواندنی (آزمایشی) یک نسخه پشتیبان آنلاین ایجاد کنید.

از نوشتن و کپی کردن داده های مخزن GIT جلوگیری کنید

مخازن GIT باید به روشی مداوم کپی شوند. آنها نباید در طول عملیات نوشتن همزمان کپی شوند ، زیرا این امر می تواند منجر به ناسازگاری یا مشکلات فساد شود. برای اطلاعات بیشتر ، شماره شماره 270422 بحث طولانی تری در مورد مشکلات احتمالی دارد.

• از حالت تعمیر و نگهداری برای قرار دادن gitlab در حالت فقط خواندنی استفاده کنید.

قبل از تهیه نسخه پشتیبان از مخازن ، خرابی صریح را با متوقف کردن تمام خدمات Gitaly ایجاد کنید:

به عنوان مثال از RSYNC با گزینه های بایگانی ، حذف و گزینه های چک استفاده کنید:

تهیه نسخه پشتیبان آنلاین از طریق مخازن مارک به عنوان فقط خواندنی (آزمایشی)

یکی از راه های تهیه نسخه پشتیبان از مخازن بدون نیاز به خرابی در سطح نمونه ، این است که در هنگام کپی کردن از داده های اساسی ، پروژه ها را به عنوان فقط خواندنی علامت گذاری کنید.

• مخازن برای یک دوره زمانی فقط خواندنی هستند که با اندازه مخزن مقیاس می شوند.
• پشتیبان گیری به دلیل علامت گذاری هر پروژه به عنوان فقط خواندنی ، زمان طولانی تر طول می کشد ، و به طور بالقوه منجر به ناسازگاری می شود. به عنوان مثال ، اختلاف احتمالی تاریخ بین آخرین داده های موجود برای اولین پروژه که در مقایسه با آخرین پروژه ای که پشتیبان گرفته می شود پشتیبان گرفته می شود.
• شبکه های چنگال باید کاملاً خواندنی باشند در حالی که پروژه های داخل آن برای جلوگیری از تغییرات احتمالی در مخزن استخر ، از آنها حمایت می شوند.

یک اسکریپت آزمایشی وجود دارد که سعی در اتوماسیون این روند در پروژه GEO Team Runbooks دارد.

با استفاده از PGBouncer ، از نصب و راه اندازی مجدد و بازیابی مجدد استفاده کنید

از طریق اتصال PGBouncer از GitLab پشتیبان گیری نکنید و یا بازگردانید. این وظایف باید PGBouncer را دور بزنند و مستقیماً به گره پایگاه داده اولیه PostgreSQL متصل شوند ، یا باعث قطع شدن GitLab شوند.

هنگامی که از نسخه پشتیبان تهیه یا بازیابی GitLab با PGBouncer استفاده می شود ، پیام خطای زیر نشان داده می شود:

هر بار که نسخه پشتیبان تهیه GitLab ، GitLab شروع به ایجاد 500 خطا و خطا در مورد جداول گمشده توسط PostgreSQL می کند:

از آنجا که اتصالات با PGBouncer در حالت جمع آوری معامله استفاده می شود ، PostgreSQL نتوانسته است طرح عمومی پیش فرض را جستجو کند. در نتیجه ، این پاکسازی مسیر جستجو باعث می شود جداول و ستون ها از بین بروند.

دور زدن PGBouncer

1. از متغیرهای محیط برای غلبه بر تنظیمات پایگاه داده برای کار پشتیبان استفاده کنید.
2. برای اتصال مستقیم به گره پایگاه داده اولیه PostgreSQL ، یک گره را پیکربندی کنید.

متغیر محیط غلبه می کند

• gitlab_backup_pghost
• gitlab_backup_pguser
• gitlab_backup_pgport
• gitlab_backup_pgpassword
• gitlab_backup_pgsslmode
• gitlab_backup_pgsslkey
• gitlab_backup_pgsslcert
• gitlab_backup_pgsslrootcert
• gitlab_backup_pgsslcrl
• gitlab_backup_pgsslcomment

به عنوان مثال ، برای غلبه بر میزبان و پورت پایگاه داده برای استفاده از 192. 168. 1. 10 و پورت 5432 با بسته Omnibus:

برای اطلاعات بیشتر در مورد آنچه این پارامترها انجام می دهد ، به مستندات PostgreSQL مراجعه کنید.

به یک سرور جدید مهاجرت کنید

برای انتقال نمونه خود به یک سرور جدید می توانید از نسخه پشتیبان تهیه و بازیابی خود استفاده کنید. در این بخش یک روش معمولی برای استقرار GitLab که روی یک سرور واحد اجرا می شود ، تشریح شده است. اگر شما GitLab Geo را اجرا می کنید ، گزینه جایگزین بازیابی فاجعه GEO برای عدم موفقیت برنامه ریزی شده است.

از پردازش داده های بدون هماهنگی توسط هر دو سرورهای جدید و قدیمی خودداری کنید ، جایی که چندین سرور می توانند به طور همزمان به هم وصل شوند و همان داده ها را پردازش کنند. به عنوان مثال ، هنگام استفاده از ایمیل ورودی ، اگر هر دو نمونه GitLab به طور همزمان در حال پردازش ایمیل باشند ، هر دو مورد برخی از داده ها را از دست می دهند. این نوع مشکل نیز می تواند با سایر خدمات ، مانند یک پایگاه داده غیر بسته بندی شده ، یک نمونه ردیس بدون بسته بندی شده یا Sidekiq بدون بسته بندی رخ دهد.

• مدتی قبل از مهاجرت ، به کاربران خود در مورد تعمیر و نگهداری برنامه ریزی شده آینده با یک پرچم پیام پخش اطلاع دهید.
• اطمینان حاصل کنید که پشتیبان گیری شما کامل و فعلی است. یک نسخه پشتیبان کامل در سطح سیستم ایجاد کنید ، یا از همه سرورهای درگیر در مهاجرت عکس بگیرید ، در صورتی که دستورات مخرب (مانند RM) به طور نادرست اجرا شوند.

سرور جدید را آماده کنید

1. کلیدهای میزبان SSH را از سرور قدیمی کپی کنید تا از هشدارهای حمله به انسان در میانه جلوگیری شود. به عنوان مثال ، به صورت دستی کلیدهای میزبان SSH سایت اصلی را تکرار کنید.
2. gitlab را به جز ایمیل ورودی نصب و پیکربندی کنید:
   1. gitlab را نصب کنید.
   2. با کپی کردن /etc /gitlab از سرور قدیمی به سرور جدید پیکربندی کنید و در صورت لزوم به روز کنید. نسخه پشتیبان تهیه شده Omnibus را بخوانید و برای جزئیات بیشتر دستورالعمل ها را بازیابی کنید.
   3. در صورت کاربرد ، ایمیل ورودی را غیرفعال کنید.

   کار جدید CI/CD را از شروع کار اولیه پس از تهیه نسخه پشتیبان و بازیابی مسدود کنید. ویرایش /etc/gitlab/gitlab. rb و موارد زیر را تنظیم کنید:

   Gitlab را متوقف کنید تا از پردازش داده های غیر ضروری و غیر عمدی بالقوه جلوگیری کنید:

   سرور جدید را پیکربندی کنید تا امکان دریافت پایگاه داده Redis و پرونده های پشتیبان GitLab را فراهم کنید:

   محتوا را از سرور قدیمی تهیه و انتقال دهید

   1. اطمینان حاصل کنید که از نسخه پشتیبان تهیه شده در سطح سیستم یا عکس فوری از سرور قدیمی برخوردار هستید.
   2. در صورت پشتیبانی از نسخه GitLab ، حالت تعمیر و نگهداری را فعال کنید.
   3. از شروع کار جدید CI/CD جلوگیری کنید:

      ویرایش /etc/gitlab/gitlab. rb ، و موارد زیر را تنظیم کنید:

      1. On the top bar, select Main menu>مدیر .
      2. On the left sidebar, select Monitoring>مشاغل پس زمینه
      3. در زیر داشبورد Sidekiq ، Cron Tab را انتخاب کرده و سپس همه را غیرفعال کنید.
      1. On the left sidebar, select Monitoring>مشاغل پس زمینه
      2. در زیر داشبورد Sidekiq ، صف ها را انتخاب کرده و سپس Live Poll را انتخاب کنید. منتظر بمانید که شلوغ و Enqueed به 0 کاهش یابد. این صف ها حاوی کارهایی هستند که توسط کاربران شما ارسال شده است. خاموش کردن قبل از اتمام این مشاغل ممکن است باعث از بین رفتن کار شود. برای تأیید پس از مهاجرت ، به اعداد نشان داده شده در داشبورد Sidekiq توجه داشته باشید.

      پایگاه داده redis را به دیسک شستشو داده و به غیر از خدمات مورد نیاز برای مهاجرت ، gitlab را متوقف کنید:

      یک نسخه پشتیبان تهیه Gitlab ایجاد کنید:

      خدمات GitLab زیر را غیرفعال کرده و با افزودن موارد زیر به پایین /etc/gitlab/gitlab. rb از راه اندازی مجدد غیر عمدی جلوگیری کنید:

      تأیید کنید که همه چیز متوقف شده است ، و تأیید کنید که هیچ خدمتی در حال اجرا نیست:

      بانک اطلاعاتی Redis و پشتیبان گیری GITLAB را به سرور جدید منتقل کنید:

      داده ها را در سرور جدید بازیابی کنید

      مجوزهای مناسب سیستم پرونده را بازیابی کنید:

      1. On the top bar, select Main menu>مدیر .
      2. On the left sidebar, select Monitoring>مشاغل پس زمینه
      3. در زیر داشبورد Sidekiq ، تأیید کنید که اعداد با آنچه در سرور قدیمی نشان داده شده است مطابقت دارد.
      4. در حالی که هنوز در زیر داشبورد Sidekiq قرار دارد ، Cron را انتخاب کرده و سپس همه را قادر می سازد تا کارهای پس زمینه دوره ای را دوباره فعال کنند.

      با از بین بردن پیکربندی NGINX سفارشی که قبلاً اضافه کرده اید ، مشاغل جدید CI/CD را از بین ببرید:

      یادداشت های اضافی

      این مستندات برای انجمن GitLab و Enterprise Edition است. ما از Gitlab.com نسخه پشتیبان تهیه می کنیم و اطمینان حاصل می کنیم که داده های شما ایمن است. با این حال ، شما نمی توانید از این روش ها برای صادرات یا تهیه نسخه پشتیبان از داده های خود از Gitlab.com استفاده کنید.

      مسائل در پایگاه داده ذخیره می شوند و نمی توانند در خود GIT ذخیره شوند.

      برای مهاجرت مخازن خود از یک سرور به سرور دیگر با نسخه به روز GitLab ، از وظیفه واردات واردات برای انجام واردات انبوه مخزن استفاده کنید. اگر به جای بازیابی پشتیبان ، یک کار واردات واردات انجام می دهید ، تمام مخازن خود را دریافت می کنید ، اما هیچ داده دیگری نیست.

      عیب یابی

      موارد زیر مشکلات احتمالی است که ممکن است با آنها روبرو شوید ، همراه با راه حل های بالقوه.

      بازیابی نسخه پشتیبان از پایگاه داده با استفاده از بسته های Omnibus خروجی هشدارها

      اگر از روشهای بازیابی پشتیبان استفاده می کنید ، ممکن است با پیام های هشدار دهنده زیر روبرو شوید:

      به شما توصیه می شود که با وجود این پیام های هشدار دهنده ، نسخه پشتیبان با موفقیت ترمیم می شود.

      کار Rake این کار را به عنوان کاربر GITLAB اجرا می کند ، که دسترسی Superuser به پایگاه داده ندارد. هنگامی که بازیابی آغاز می شود ، به عنوان کاربر GITLAB نیز اجرا می شود ، اما همچنین سعی می کند اشیاء را که به آنها دسترسی ندارند تغییر دهد. این اشیاء هیچ تاثیری در تهیه نسخه پشتیبان از پایگاه داده یا بازیابی ندارند ، اما یک پیام هشدار دهنده را نشان می دهند.

      • ردیاب شماره PostgreSQL:
        • فوق العاده بودن نیست
        • داشتن صاحبان مختلف

        وقتی پرونده اسرار از بین می رود

        اگر از پرونده اسرار نسخه پشتیبان تهیه نکردید ، باید چندین مرحله را انجام دهید تا دوباره GitLab دوباره کار کنید.

        پرونده اسرار وظیفه ذخیره کلید رمزگذاری برای ستونهای حاوی اطلاعات حساس و حساس را بر عهده دارد. اگر کلید از بین برود ، GitLab نمی تواند آن ستون ها را رمزگشایی کند ، و از دسترسی به موارد زیر جلوگیری می کند:

        • مشاغل گیر
        • 500 خطا

        در این حالت ، شما باید تمام نشانه های مربوط به متغیرهای CI/CD و احراز هویت دونده را مجدداً تنظیم کنید ، که در بخش های بعدی با جزئیات بیشتری توضیح داده شده است. پس از تنظیم مجدد نشانه ها ، باید بتوانید از پروژه خود بازدید کنید و مشاغل دوباره شروع به کار می کنند.

        از اطلاعات در بخش های زیر در معرض خطر خود استفاده کنید.

        تأیید کنید که همه مقادیر را می توان رمزگشایی کرد

        می توانید تعیین کنید که آیا پایگاه داده شما حاوی مقادیری است که با استفاده از یک کار Rake نمی توان رمزگشایی کرد.

        پشتیبان گرفتن

        شما باید مستقیماً داده های GITLAB را اصلاح کنید تا در پرونده اسرار گمشده خود کار کنید.

        تأیید هویت دو عاملی کاربر (2FA)

        کاربران دارای 2FA فعال نمی توانند وارد GitLab شوند. در این حالت ، شما باید 2FA را برای همه غیرفعال کنید ، پس از آن کاربران باید 2FA را دوباره فعال کنند.

        تنظیم مجدد متغیرهای CI/CD

        کنسول پایگاه داده را وارد کنید:

        برای omnibus gitlab 14. 1 و قبل از آن:

        برای omnibus gitlab 14. 2 و بعد:

        برای نصب از منبع ، Gitlab 14. 1 و قبل از آن:

        برای نصب از منبع ، Gitlab 14. 2 و بعد:

        جداول CI_GROUP_VARIABLES و CI_VARIABLES را بررسی کنید:

        این متغیرهایی است که برای حذف آنها نیاز دارید.

        اگر گروه یا پروژه خاصی را که می خواهید متغیرها را حذف کنید ، می دانید ، می توانید یک عبارت را درج کنید تا آن را در حذف خود مشخص کنید:

        ممکن است شما نیاز به پیکربندی مجدد یا راه اندازی مجدد GitLab برای تغییر داشته باشید.

        تنظیم مجدد نشانه های ثبت نام دونده

        کنسول پایگاه داده را وارد کنید:

        برای omnibus gitlab 14. 1 و قبل از آن:

        برای omnibus gitlab 14. 2 و بعد:

        برای نصب از منبع ، Gitlab 14. 1 و قبل از آن:

        برای نصب از منبع ، Gitlab 14. 2 و بعد:

        تمام نشانه ها را برای پروژه ها ، گروه ها و کل نمونه ها پاک کنید:

        عملیات به روزرسانی نهایی ، دوندگان را از قادر به انتخاب مشاغل جدید متوقف می کند. شما باید دوندگان جدید را ثبت کنید.

        تنظیم مجدد مشاغل خط لوله

        کنسول پایگاه داده را وارد کنید:

        برای omnibus gitlab 14. 1 و قبل از آن:

        برای omnibus gitlab 14. 2 و بعد:

        برای نصب از منبع ، Gitlab 14. 1 و قبل از آن:

        برای نصب از منبع ، Gitlab 14. 2 و بعد:

        تمام نشانه ها را برای مشاغل در انتظار پاک کنید:

        یک استراتژی مشابه می تواند برای ویژگی های باقیمانده استفاده شود. با از بین بردن داده هایی که قابل رمزگشایی نیستند ، GitLab را می توان به بهره برداری بازگرداند و داده های گمشده را می توان به صورت دستی جایگزین کرد.

        ادغام ها و وب سایت ها را برطرف کنید

        اگر اسرار خود را از دست داده اید ، صفحات تنظیمات یکپارچه سازی و صفحات تنظیمات Webhooks احتمالاً 500 پیام خطایی را نشان می دهند.

        کنسول پایگاه داده را وارد کنید:

        برای omnibus gitlab 14. 1 و قبل از آن:

        برای omnibus gitlab 14. 2 و بعد:

        برای نصب از منبع ، Gitlab 14. 1 و قبل از آن:

        برای نصب از منبع ، Gitlab 14. 2 و بعد:

        جداول زیر را کوتاه کنید:

        پس از بازگرداندن از نسخه پشتیبان ، ثبت نام کانتینر

        اگر از رجیستری کانتینر استفاده می کنید ، فشار به رجیستری ممکن است پس از بازگرداندن نسخه پشتیبان شما در نمونه Omnibus gitlab پس از بازگرداندن داده های رجیستری ، شکست بخورد.

        این خرابی ها به مسائل مجوز در سیاهههای مربوط به رجیستری اشاره می کنند ، مشابه:

        این مسئله در اثر بازگرداندن به عنوان کاربر غیرقانونی کاربر ایجاد می شود ، که قادر به اختصاص مالکیت صحیح به پرونده های رجیستری در طی مراحل بازیابی نیست (شماره شماره 62759).

        تا دوباره رجیستری خود را کار کنید:

        اگر مکان پیش فرض سیستم فایل را برای رجیستری تغییر دادید ، به جای/var/opt/gitlab/gitlab-rails/مشترک/رجیستری/docker ، Chown را در مقابل مکان سفارشی خود اجرا کنید.

        پشتیبان گیری با خطای GZIP نتواند کامل شود

        هنگام اجرای نسخه پشتیبان ، ممکن است یک پیام خطای GZIP دریافت کنید:

        • تأیید کنید که فضای دیسک کافی برای عملکرد GZIP وجود دارد.
        • اگر از NFS استفاده می شود ، بررسی کنید که آیا زمان تنظیم گزینه Mount تنظیم شده است یا خیر. پیش فرض 600 است و تغییر این به مقادیر کوچکتر منجر به این خطا می شود.

        پشتیبان گیری با نام پرونده بیش از حد طولانی خطای

        در حین تهیه نسخه پشتیبان ، می توانید نام پرونده را بیش از حد خطای طولانی دریافت کنید (شماره شماره 354984). مثلا:

        این مشکل از تکمیل اسکریپت پشتیبان جلوگیری می کند. برای رفع این مشکل ، باید نام پرونده ها را ایجاد کنید که باعث مشکل می شود. حداکثر 246 کاراکتر ، از جمله پسوند پرونده ، مجاز است.

        مراحل موجود در این بخش به طور بالقوه می تواند منجر به از بین رفتن داده ها شود. تمام مراحل باید به ترتیب داده شده انجام شود.

        • تمیز کردن پرونده های بارگذاری شده از راه دور که در پایگاه داده ردیابی نمی شوند.
        • کوتاه کردن نام پرونده ها در پایگاه داده.
        • دوباره کار پشتیبان گیری.

        فایلهای بارگذاری شده از راه دور را پاک کنید

        یک مسئله شناخته شده باعث شد که آپلودهای فروشگاه شیء پس از حذف منبع والدین باقی بماند. این مسئله حل شد

        اگر در پایگاه داده GitLab وجود نداشته باشد ، تمام پرونده های بارگذاری فروشگاه Object را که می توانند به یک فهرست گمشده و یافت شده منتقل شوند ، لیست کنید:

        اگر مطمئن هستید که می خواهید این پرونده ها را حذف کرده و تمام پرونده های بارگذاری نشده مرجع را حذف کنید ، اجرا کنید:

        نام های پرونده ارجاع شده توسط پایگاه داده را کوتاه کنید

        • در جدول بارگذاری.
        • در منابع یافت شدههر مرجع یافت شده از سایر جداول و ستون های پایگاه داده.
        • در سیستم فایل

        کنسول پایگاه داده را وارد کنید:

        برای omnibus gitlab 14. 2 و بعد:

        برای omnibus gitlab 14. 1 و قبل از آن:

        برای نصب از منبع ، Gitlab 14. 2 و بعد:

        برای نصب از منبع ، Gitlab 14. 1 و قبل از آن:

        جدول بارگذاری را برای نام های پرونده طولانی تر از 246 کاراکتر جستجو کنید:

        پرس و جو زیر سوابق بارگذاری را با نام پرونده های طولانی تر از 246 کاراکتر در دسته های 0 تا 10000 انتخاب می کند. این عملکرد را در نمونه های بزرگ GitLab با جداول دارای هزار رکورد بهبود می بخشد.

        • nust_filename: نام پرونده ای که در حال حاضر بیش از 246 نویسه طول دارد.
        • new_filename: نام پرونده ای که حداکثر به 246 کاراکتر کوتاه شده است.
        • New_Path: مسیر جدید با توجه به نام New_filename (کوتاه).

        پس از تأیید نتایج دسته ای ، باید با استفاده از دنباله زیر از اعداد (10000 به 20000) اندازه دسته (row_id) را تغییر دهید. این روند را تکرار کنید تا به آخرین رکورد در جدول بارگذاری برسید.

        پرونده های موجود در جدول آپلودها را از نامهای طولانی به نام های پرونده کوتاه جدید تغییر نام دهید. پرس و جو زیر به روزرسانی را بازگرداند ، بنابراین می توانید نتایج را با خیال راحت در یک بسته بندی معامله بررسی کنید:

        پس از تأیید نتایج به روزرسانی دسته ای ، باید با استفاده از دنباله زیر از اعداد (10000 تا 20000) اندازه دسته (row_id) را تغییر دهید. این روند را تکرار کنید تا به آخرین رکورد در جدول بارگذاری برسید.

        تأیید کنید که نام های جدید از پرس و جو قبلی موارد مورد انتظار هستند. اگر مطمئن هستید که می خواهید سوابق موجود در مرحله قبل به 246 کاراکتر را کوتاه کنید ، موارد زیر را اجرا کنید: