Ένα backup GitLab που δεν κάνει restore είναι απλώς ένα μεγάλο αρχείο

Οι περισσότερες self-hosted εγκαταστάσεις GitLab έχουν ένα νυχτερινό job backup, και οι περισσότεροι από αυτούς που το έστησαν δεν έχουν κάνει ποτέ restore από αυτό. Αυτό είναι πρόβλημα, επειδή το αρχείο που παράγει το GitLab είναι εσκεμμένα ελλιπές. Κάντε restore σε φρέσκο server χωρίς τα αρχεία που αφήνει έξω, και τα repositories σας επιστρέφουν ενώ οι μεταβλητές CI, οι ρυθμίσεις two-factor και οι εγγραφές runners γίνονται μη αναγνώσιμα δεδομένα. Να τι περιέχει ένα πλήρες backup GitLab, πώς να το μετακινήσετε χωρίς να αποδυναμώσετε την ασφάλειά σας, και πώς να αποδείξετε ότι δουλεύει.

Τι περιλαμβάνει το backup task, και τι αφήνει έξω

Σε εγκατάσταση με πακέτο (Omnibus), το backup task είναι:

sudo gitlab-backup create STRATEGY=copy

Γράφει ένα μόνο αρχείο tar στον κατάλογο backup, συνήθως /var/opt/gitlab/backups. Αυτό το αρχείο περιέχει τη βάση δεδομένων, τα Git repositories, uploads, αντικείμενα LFS, artifacts των CI jobs, pages, packages και, αν είναι ενεργοποιημένο, το container registry. Το STRATEGY=copy αντιγράφει τα δεδομένα πριν τα αρχειοθετήσει, κάτι που αποφεύγει σφάλματα όταν αρχεία αλλάζουν κατά τη διάρκεια ενός μακρύ backup σε πολυάσχολη εγκατάσταση.

Τι δεν περιέχει, επίτηδες:

• /etc/gitlab/gitlab-secrets.json, τα κλειδιά που κρυπτογραφούν ευαίσθητες στήλες στη βάση δεδομένων.
• /etc/gitlab/gitlab.rb, η διαμόρφωσή σας.
• Πιστοποιητικά και κλειδιά TLS κάτω από το /etc/gitlab/ssl, αν τα κρατάτε εκεί.
• Τα SSH host keys στο /etc/ssh, τα οποία οι clients των developers σας έχουν ήδη καταγράψει.

Το GitLab τα αφήνει έξω ώστε ένα μόνο κλεμμένο αρχείο να μην περιέχει και τα κρυπτογραφημένα δεδομένα και το κλειδί που τα αποκρυπτογραφεί. Είναι σωστή λογική, και μεταθέτει σε εσάς τη δουλειά να τα κρατάτε σε backup χωριστά.

Γιατί το αρχείο secrets έχει τόση σημασία

Μεταβλητές CI/CD, tokens εγγραφής runners, seeds two-factor authentication, κωδικοί integrations και αρκετές άλλες τιμές κρυπτογραφούνται στη βάση δεδομένων με κλειδιά από το gitlab-secrets.json. Κάντε restore τη βάση δεδομένων χωρίς το αντίστοιχο αρχείο secrets και το GitLab ξεκινά, τα repositories είναι εκεί, και μετά τα pipelines αποτυγχάνουν, οι χρήστες με two-factor authentication δεν μπορούν να συνδεθούν, και οι runners χρειάζονται ξανά εγγραφή.

Κρατήστε backup τον κατάλογο διαμόρφωσης ως ξεχωριστό artifact:

sudo gitlab-ctl backup-etc --backup-path /var/opt/gitlab/config-backups

Αυτό παράγει ένα tar του /etc/gitlab, μαζί με το αρχείο secrets. Κρατήστε το σε διαφορετικό μέρος από το αρχείο δεδομένων, με αυστηρότερη πρόσβαση, και κρατήστε τα ζεύγη που ταιριάζουν μαζί στην πολιτική διατήρησής σας. Ένα αρχείο δεδομένων της Δευτέρας και ένα αρχείο secrets της Πέμπτης μπορεί να μη συμφωνούν μεταξύ τους αν κάτι ανανεώθηκε στο ενδιάμεσο.

Για εγκαταστάσεις σε container οι εντολές είναι οι ίδιες, εκτελούνται μέσα στο container, και το /etc/gitlab είναι όποιο volume έχετε αντιστοιχίσει σε αυτό. Βεβαιωθείτε ότι αυτό το volume είναι μέρος όσων κρατάτε σε backup. Είναι εύκολο να κρατάτε backup μόνο το volume δεδομένων.

Τραβήξτε το backup, μην το σπρώχνετε

Το συνηθισμένο μοτίβο είναι ένα cron job στον server του GitLab που αντιγράφει το αρχείο σε έναν host backup. Αυτό σημαίνει ότι ο server του GitLab κρατά διαπιστευτήρια που μπορούν να γράψουν στα backups σας. Αν το GitLab παραβιαστεί, παραβιάζεται και ο τρόπος να φτάσει κανείς και να διαγράψει τα backups.

Αντιστρέψτε την κατεύθυνση. Ο host backup συνδέεται στο GitLab και φέρνει τα αρχεία. Το GitLab δεν κρατά διαπιστευτήρια για τον host backup και δεν έχει διαδρομή δικτύου προς αυτόν. Από την πλευρά του GitLab, περιορίστε τι μπορεί να κάνει το κλειδί του host backup με forced command στο authorized_keys:

command="/usr/local/bin/backup-send",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... backup-puller

όπου το backup-send είναι ένα μικρό script που δεν κάνει τίποτα άλλο από το να στέλνει το νεότερο αρχείο δεδομένων και το αντίστοιχο αρχείο διαμόρφωσης. Στον host backup, το job φέρνει και τα δύο, ελέγχει τα μεγέθη και τα checksums τους, και ειδοποιεί αν κάποιο λείπει ή είναι παλαιότερο από το αναμενόμενο.

Μετά επιβάλετε την κατεύθυνση στο firewall: ο host backup μπορεί να ανοίγει συνδέσεις προς το GitLab, τίποτα στο δίκτυο του GitLab δεν μπορεί να ανοίγει συνδέσεις προς τον host backup.

Κανόνες restore που αξίζει να ξέρετε πριν τους χρειαστείτε

Ένα backup GitLab γίνεται restore μόνο στην ίδια έκδοση και edition GitLab που το δημιούργησε. Γράψτε την έκδοση στο όνομα του αρχείου ή σε ένα συνοδευτικό αρχείο την ώρα του backup:

sudo gitlab-rake gitlab:env:info > gitlab-env-$(date +%F).txt

Αν χάσετε τον server και ο μόνος installer που μπορείτε να βρείτε είναι νεότερος, θα εγκαταστήσετε πρώτα την παλιά έκδοση, θα κάνετε restore, και μετά θα αναβαθμίσετε κατά μήκος της υποστηριζόμενης διαδρομής. Το να το ξέρετε εκ των προτέρων μετατρέπει μια μεγάλη νύχτα σε προγραμματισμένη διαδικασία.

Το ίδιο το restore, σε φρέσκια εγκατάσταση της αντίστοιχης έκδοσης:

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# put gitlab-secrets.json and gitlab.rb back into /etc/gitlab first
sudo gitlab-ctl reconfigure
sudo gitlab-backup restore BACKUP=<archive-id>
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true
sudo gitlab-rake gitlab:doctor:secrets

Η τελευταία εντολή είναι αυτή που μετράει. Το gitlab:doctor:secrets περνά από τις κρυπτογραφημένες στήλες και αναφέρει όσες δεν μπορεί να αποκρυπτογραφήσει. Αν αναφέρει αποτυχίες, το αρχείο secrets και το αρχείο δεδομένων σας δεν ανήκουν μαζί.

Αποδείξτε το με πρόγραμμα

Ένα restore που δεν έχετε δοκιμάσει είναι μια ελπίδα. Κάντε το ρουτίνα:

1. Χτίστε μια αναλώσιμη VM σε απομονωμένο δίκτυο χωρίς διαδρομή προς την παραγωγή.
2. Εγκαταστήστε την έκδοση GitLab που καταγράφηκε με το backup.
3. Κάντε restore το νεότερο ζεύγος διαμόρφωσης και δεδομένων.
4. Τρέξτε gitlab:check και gitlab:doctor:secrets.
5. Κάντε clone ένα γνωστό repository, συγκρίνετε το τελευταίο commit hash του με την παραγωγή, και ανοίξτε τη σελίδα μεταβλητών CI ενός project.
6. Καταγράψτε το αποτέλεσμα και τον χρόνο που πήρε, και μετά καταστρέψτε τη VM.

Χρονομετρήστε το, επίσης. Η διάρκεια του restore είναι ο πραγματικός σας χρόνος ανάκαμψης, και είναι συνήθως μεγαλύτερος απ' όσο μαντεύει ο κόσμος σε μεγάλη εγκατάσταση.

Ένα δεύτερο, ανεξάρτητο αντίγραφο του κώδικα

Το πλήρες backup προστατεύει ολόκληρη την εφαρμογή. Για τα ίδια τα repositories, ένα απλό mirror σάς δίνει ένα δεύτερο αντίγραφο που δεν εξαρτάται καθόλου από τα εργαλεία του GitLab:

git clone --mirror git@gitlab.example.com:group/project.git
git -C project.git remote update --prune

Τρέξτε το από την πλευρά του backup για τα repositories που δεν έχετε την πολυτέλεια να χάσετε. Δεν θα κάνει restore issues ή merge requests, αλλά σημαίνει ότι το ιστορικό του κώδικά σας επιβιώνει ακόμη και ένα αρχείο backup που δεν μπορείτε να διαβάσετε.

Η σύντομη εκδοχή

• Το gitlab-backup create είναι το μισό backup. Το gitlab-ctl backup-etc είναι το άλλο μισό.
• Κρατήστε secrets και δεδομένα σε ζεύγη που ταιριάζουν, αποθηκευμένα χωριστά, με αυστηρότερη πρόσβαση στα secrets.
• Η πλευρά του backup τραβά. Το GitLab δεν έχει διαδρομή προς τα δικά του backups.
• Καταγράψτε την έκδοση GitLab με κάθε αρχείο.
• Κάντε restore με πρόγραμμα, και τρέξτε gitlab:doctor:secrets κάθε φορά.

Έτσι προστατεύουμε τις εγκαταστάσεις GitLab που λειτουργούμε για πελάτες στα δικά μας datacenters. Αν θέλετε να ελεγχθεί η δική σας διαδρομή restore, ευχαρίστως να βοηθήσουμε.

Μιλήστε με έναν μηχανικό

related line: Σχετικά: Managed source control σε GitLab · Managed Nextcloud για έγγραφα γραφείου

footer line: Δημοσιεύτηκε 22 Οκτωβρίου 2026. Όλες οι σημειώσεις από το πεδίο