Kendi Storage'ınızdan Restore
Kendi storage sağlayıcınızı (BYOS) kullanıyorsanız GitSec'in yazdığı her backup dosyası storage'ınızda kalır. Bu dosyalardan bir repository'yi Git ve bulut sağlayıcınızın araçlarıyla GitHub, GitLab veya Bitbucket'a kendiniz geri yükleyebilirsiniz; GitSec'e erişiminiz olmasa bile.
GitSec'e hâlâ giriş yapabiliyorsanız Restore Wizard daha kolay yoldur: repository'yi oluşturur, pull request, issue ve diğer scope'ları (hedef sağlayıcıya göre) sizin için geri yükler. Bu sayfayı GitSec'e erişemediğinizde kullanın, örneğin aboneliğiniz sona erdikten sonra.
Gerekenler
- Backup'ların bulunduğu storage'a okuma erişimi (AWS S3, Azure Blob, Google Drive, Onedrive veya Huawei OBS).
- Bilgisayarınızda kurulu Git.
- Hedef sağlayıcıda repository oluşturabilen bir hesap ve push yöntemi: SSH anahtarı veya access token.
- Backup dosyası ve açılmış repository için yeterli boş disk alanı.
Backup'lar Nasıl Düzenlenir
GitSec her backup'ın dosyalarını kendi klasöründe tutar:
<owner>_<repository>/<date>_<execution-id>/<scope>/<file>
| Bölüm | Anlamı |
|---|---|
<owner>_<repository> | GitHub owner'ı, GitLab namespace'i veya Bitbucket workspace'i ile repository adı. GitLab alt gruplarında / yerine _ kullanılır (örneğin group_subgroup_repo). |
<date>_<execution-id> | Backup'ın başladığı zaman, UTC olarak yyyyMMdd-HHmmss biçiminde, ardından backup'ın execution ID'si. |
<scope> | Yedeklenen her scope için bir klasör: SourceCode, RepositoryMetadata, PullRequests, PullRequestComments, Issues, Releases, Collaborators. |
AWS S3 ve Huawei OBS'te klasörler bucket kökünden başlar. Azure Blob'da storage'ı bağlarken belirlediğiniz Folder Path içindedir. Onedrive'da Apps > GitSec içinde, Google Drive'da GitSec'in oluşturduğu klasörün içindedir.
Belirli bir backup'ı bulmak için klasör adındaki tarihi ve execution ID'yi eşleştirin. Execution ID her backup anlık görüntüsü için Restore Wizard'ın 2. adımında gösterilir.
Her Scope Ne İçerir
| Klasör | Dosyalar | Git ile restore edilebilir mi? |
|---|---|---|
SourceCode | <owner>_<repository>_<date>_source.tar adlı tek bir .tar dosyası. Repository'nin tam bir mirror'ını içerir: tüm branch'ler, tag'ler ve commit geçmişi. | Evet. Restore edeceğiniz dosya budur. |
RepositoryMetadata | GitHub: varsayılan branch'teki dosyaların geçmişsiz arşivi. Dosyanın adı ..._repository.tar.gz olsa da düz bir tar arşividir; tar -xf ile açın. GitLab ve Bitbucket: repository ayarlarını içeren bir JSON dosyası. | Hayır. Başvuru için saklayın. |
PullRequests, PullRequestComments, Issues, Releases, Collaborators | Scope başına bir veya daha fazla JSON dosyası. | Hayır. Başvuru için saklayın veya kendi script'lerinizle hedef sağlayıcının API'si üzerinden içe aktarın. |
Kendi storage'ınızı siz oluşturur ve yönetirsiniz; GitSec'e yalnız backup dosyalarını yönetmek için gereken minimum yetkiyi verirsiniz. Bu nedenle GitSec, storage'ınızdaki backup'ları normal dosyalar olarak tutar: GitSec tarafından şifrelenmez ve sıkıştırılmaz, böylece onları kendi araçlarınızla açıp restore edebilirsiniz. Bekleyen veriyi korumak için storage sağlayıcınızın şifrelemesini açın, örneğin AWS S3'te SSE-S3 veya SSE-KMS. GitSec Storage üzerindeki backup'lar ise her zaman GitSec tarafından şifrelenir.
Adım 1: Kaynak Kod Arşivini İndirin
Restore etmek istediğiniz backup klasörünü açın ve SourceCode klasöründeki .tar dosyasını indirin.
| Storage | Nasıl indirilir |
|---|---|
| AWS S3 | S3 konsolundan veya AWS CLI ile: aws s3 cp "s3://<bucket>/<path>/<file>_source.tar" . |
| Azure Blob | Azure portalından (Storage accounts > container'ınız) veya Azure CLI ile: az storage blob download --connection-string "<connection-string>" --container-name <container> --name "<path>/<file>_source.tar" --file <file>_source.tar. SAS URL kullanıyorsanız connection string, container ve ad yerine --blob-url "<blob yolunu içeren SAS URL>" verin. |
| Huawei OBS | OBS konsolundan veya obsutil ile (önce obsutil config çalıştırın): obsutil cp "obs://<bucket>/<path>/<file>_source.tar" ./<file>_source.tar |
| Google Drive | Google Drive'da GitSec klasörünü açın, backup klasörüne gidin ve dosyayı indirin. |
| Onedrive | Onedrive'da Apps > GitSec klasörünü açın, backup klasörüne gidin ve dosyayı indirin. |
Adım 2: Repository'yi Arşivden Çıkarın
Arşiv, üst klasörü olmayan bir bare Git repository'si içerir. Yeni ve boş bir klasöre çıkarın:
mkdir my-repo.git
tar -xf <file>_source.tar -C my-repo.git
Repository'nin eksiksiz olduğunu kontrol edin, branch ve tag'lerini görün:
git -C my-repo.git fsck
git -C my-repo.git branch -a
git -C my-repo.git tag
Varsayılan branch'i not edin; Adım 5'te gerekecek:
git -C my-repo.git symbolic-ref --short HEAD
Adım 3: Hedef Sağlayıcıda Boş Bir Repository Oluşturun
Yeni bir repository oluşturun ve boş bırakın: README, lisans veya .gitignore eklemeyin. Aksi halde ilk push reddedilir.
- GitHub: New repository'ye tıklayın, owner'ı seçin, bir ad girin; README,
.gitignoreveya lisans eklemeyin. - GitLab: New project > Create blank project'e tıklayın, grubu veya kişisel namespace'inizi seçin ve Initialize repository with a README işaretini kaldırın. Bu adım GitLab.com ve Self-Managed GitLab için aynıdır.
- Bitbucket: Create > Repository'ye tıklayın, workspace ve projeyi seçin, Include a README? ve Include .gitignore? için No seçin.
Repository'nin clone URL'sini (HTTPS veya SSH) kopyalayın.
Adım 4: Branch'leri ve Tag'leri Push Edin
Tüm branch'leri ve tag'leri yeni repository'ye push edin:
cd my-repo.git
git push <clone-url> 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'
HTTPS ile push ederken parola olarak bir access token kullanın: GitHub veya GitLab'da personal access token, Bitbucket'ta API token.
Mirror backup, sağlayıcının iç referanslarını da içerir; örneğin GitHub'da refs/pull/*, GitLab'da refs/merge-requests/*. git push --mirror bunları da push etmeye çalışır ve hedef sağlayıcı deny updating a hidden ref gibi hatalarla reddeder. Yukarıdaki gibi yalnız branch ve tag push etmek bunu önler.
Adım 5: Restore Edilen Repository'yi Kontrol Edin
- Sağlayıcı farklı bir branch seçtiyse, Adım 2'de not ettiğiniz varsayılan branch'i repository ayarlarından belirleyin.
- Branch ve tag sayılarını Adım 2'deki çıktıyla karşılaştırın, örneğin
git ls-remote --heads --tags <clone-url>ile. - Git'in taşımadıklarını yeniden kurun: branch koruma kuralları, webhook'lar, CI/CD ayarları ve secret'lar, üye erişimleri.
Sınırlamalar
- Bu yolla yalnız kod ve geçmiş restore edilir. Pull request, issue, release, collaborator ve repository ayarları JSON dosyaları olarak tutulur ve Git ile içe aktarılamaz. Bunları otomatik geri yüklemek için Restore Wizard'ı kullanın; her sağlayıcının neyi desteklediği için Neler Restore Edilebilir? bölümüne bakın.