Hi,
I am running the latest Gitlab CE SCM
. I am referring to Back up and restore GitLab | GitLab. Does gitlab-backup create support both incremental and full backup?
Thanks in Advance. I look forward to hearing from you.
Best Regards,
Kaushal
Hi,
Gitlab creates backups in /var/opt/gitlab/backups (or at least on Omnibus version), your location may vary if compiled form code. I believe these are full backups of the database.
Other than this, then you have to create your own backup strategy using appropriate backup tools. I, for example backup my server with a Synology NAS and the backup software on there does appropriate full weekly/monthly/yearly backups as well as incremental/differential.
Gitlab is not backup software, therefore you will need additional tools to do this.
No, gitlab-backup always creates a full backup. There is an issue to provide incremental backups.
There are more in those than a dump of the database, and that’s where the largest effects of incremental backups can be gained.
gitlab-backup does create files in /var/opt/gitlab/backups, but it also supports uploading them to somewhere else after completion, and as iwalker says you can do whatever you want with those files, you won’t get the same savings as incremental backups from GitLab’s side would give.
If I may advertise a feature I contributed myself, ‘SKIP=tar’ does make it a little bit easier for whatever software you put after gitlab-backup to detect parts that haven’t changed, it still packs files together though.
1 Like
Thanks @grove @iwalker for the reply and suggestions. I am using rclone (https://rclone.org/) as a backup application. Please let me know what all files and directories I need to carry out incremental backup as per the below directory structure.
[root@gitlab gitlab]# pwd
/opt/gitlab
[root@gitlab gitlab]# ll
total 2600
drwxr-xr-x. 2 root root 153 Jan 22 21:20 bin
-rw-r–r–. 1 root root 193320 Jan 21 23:04 dependency_licenses.json
drwxr-xr-x. 18 root root 215 Jan 22 21:29 embedded
drwxr-xr-x. 12 root root 4096 Jan 22 21:29 etc
drwxr-xr-x. 2 root root 4096 Jan 21 23:04 init
-rw-r–r–. 1 root root 2390042 Jan 21 23:04 LICENSE
drwxr-xr-x. 2 root root 4096 Jan 22 21:21 licenses
drwxr-xr-x. 2 root root 4096 Jan 22 21:22 LICENSES
drwxr-xr-x. 2 root root 4096 Jan 21 23:04 service
drwxr-xr-x. 20 root root 4096 Jan 21 23:04 sv
drwxr-xr-x. 4 root root 33 May 22 2020 var
-rw-r–r–. 1 root root 31937 Jan 21 23:04 version-manifest.json
-rw-r–r–. 1 root root 12135 Jan 21 23:04 version-manifest.txt
[root@gitlab gitlab]#
Please suggest further. Thanks in Advance.
Best Regards,
Kaushal
Hi,
Checking in again if someone can pitch in for my earlier email to this forum. Thanks in Advance.
Best Regards,
Kaushal
Hi we are running gitlab on eks cluster with help deployed ,we are able to full backups but data is increasing day by day we are planning to take incremental backup how can we do that? my gitlab version is 13.11.4 and how to increase space/ pvc/ pv without deleting it?
You cannot do an incremental backup. It was already posted above that it isn’t possible. If you want to do incremental backups, then you will need to use some other kind of backup solution outside of the Gitlab backup process. That would most likely mean stopping Gitlab whilst making a backup be it full backup, differential or incremental depending on the backup software that you are using.
As for resizing partitions without deleting the partition, install a package called cloud-utils, inside this package is a program called growpart. Obviously, this is only going to work if the partition is the last partition on the disk. You cannot grow partitions that have partitions that exist after it. For example, if a disk /dev/sda has two partitions /dev/sda1 and /dev/sda2, then you cannot grow partition /dev/sda1. You can only grow /dev/sda2. Assuming that you don’t have this problem, and wish for /dev/sda2 to be expanded, then you do this:
growpart /dev/sda 2
once that has done, you can then look at allocating the space to LVM. Chances are, all you will need to do that is:
pvresize /dev/sda2
lvresize volgroup/volname -l +100%FREE
that will resize the volgroup/volname to use 100% of all the free space. After that you will need to resize the filesystem using the appropriate package for the filesystem in use, eg: resize2fs for ext4, xfs_grow for xfs, and so on.
As always when making changes to partitions, take a backup of your system before you do it in case it goes wrong.