La sauvegarde ou la restauration ont-elles un impact sur les performances ?
Oui, mais de façon minime, en particulier pour les charges de travail de production.
- Lors de la sauvegarde et de la restauration, les tâches de maintenance et de stockage en arrière-plan de Git sont suspendues pour les étapes concernées (par exemple, les référentiels, le stockage). Cela peut entraîner un retard temporaire visible dans les métriques de l’instance.
- Pour les référentiels fréquemment mis à jour, les performances peuvent se dégrader si les tâches de maintenance sont retardées pendant des périodes prolongées.
- Les opérations de sauvegarde s’exécutent avec une faible priorité au niveau du processeur et des E/S afin de réduire l’impact sur l’utilisateur. Vous pouvez toutefois observer des pics temporaires dans l’utilisation des ressources.
Nous vous recommandons d’attendre que le retard de maintenance soit entièrement rattrapé avant de lancer une autre sauvegarde.
Comment sont gérées les sauvegardes MS SQL Server ?
Si GitHub Actionsest activé, le service sauvegarde la base de données MS SQL Server selon une cadence hiérarchisée :
- Sauvegarde complète (F) : instantané complet.
- Sauvegarde différentielle (D) : modifications depuis la dernière sauvegarde complète.
- Sauvegarde du journal des transactions (T) : modifications détaillées depuis la dernière sauvegarde complète ou différentielle.
La fréquence des sauvegardes est contrôlée par le paramètre MSSQL Backup Cadence dans Management Console. Au fil du temps, un instantané comprend :
- 1 sauvegarde complète
- 0 ou plusieurs sauvegardes différentielles
- 1 ou plusieurs sauvegardes de journal des transactions
Exemple de chronologie de sauvegarde
M---8:00--16:00---T---8:00--16:00---W... (timeline)
F-----------------F-----------------F... (full backup)
#-----D-----D-----#-----D-----D-----#... (differential backup)
T--T--T--T--T--T--T--T--T--T--T--T--T... (transaction log backup)
Pour optimiser l’espace, les liens physiques renvoient vers des sauvegardes créées précédemment. Seuls les nouveaux fichiers de sauvegarde sont transférés à chaque exécution. Chaque nouvel instantané complet ou différentiel devient la ligne de base pour les futurs journaux de transactions.
Lors de la restauration, les sauvegardes sont restaurées dans l’ordre suivant : complète, différentielle et journaux de transactions.
Que sont les données de point de référence ?
Chaque instantané comprend un journal de point de référence dans le répertoire benchmarks/. Ce journal indique la durée de chaque étape de sauvegarde et peut aider à identifier les goulots d’étranglement au niveau des performances.
ghe-backup-settings took 2s
ghe-export-authorized-keys took 0s
ghe-export-ssh-host-keys took 0s
ghe-backup-mysql-binary took 9s
ghe-backup-mysql took 9s
ghe-backup-minio took 0s
ghe-backup-redis took 1s
ghe-backup-es-audit-log took 1s
ghe-backup-repositories - Generating routes took 3s
ghe-backup-repositories - Fetching routes took 0s
ghe-backup-repositories - Processing routes took 0s
ghe-backup-pages - hostname took 1s
ghe-backup-pages took 1s
ghe-backup-storage - Generating routes took 2s
ghe-backup-storage - Fetching routes took 0s
ghe-backup-storage - Processing routes took 0s
ghe-backup-git-hooks took 0s
ghe-backup-es-rsync took 2s