You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 19, 2019. It is now read-only.
Currently installed backup logic in /etc/cron.d/GitLab_backups is sub-optimal from a performance perspecctive
Expected Behavior:
Maximize S3 performance to be more equivalent to those outlined in AWS documentation
Actual Behavior:
Backup/restore slower than could be. Mostly not a problem, now, but will become a problem as backed-up dataset grows in size (particularly number of elements backed up)
Fix recommendation:
Change current backup method from an s3 sync of the GitLab content to a tar cf - <GITLAB_CONTENT> | s3 cp - s3://<BUCKET>/<KEY>/<TAR_FILE> method
Problem Description:
Currently installed backup logic in
/etc/cron.d/GitLab_backupsis sub-optimal from a performance perspecctiveExpected Behavior:
Maximize S3 performance to be more equivalent to those outlined in AWS documentation
Actual Behavior:
Backup/restore slower than could be. Mostly not a problem, now, but will become a problem as backed-up dataset grows in size (particularly number of elements backed up)
Fix recommendation:
Change current backup method from an
s3 syncof the GitLab content to atar cf - <GITLAB_CONTENT> | s3 cp - s3://<BUCKET>/<KEY>/<TAR_FILE>method