# Gitlab-rake gitlab:backup:create VS Gitlab-backup

**URL:** <https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364>\
**Category:** Self-managed\
**Tags:** backup\
**Created:** [May 12, 2023, 1:41pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364 "2023-05-12T13:41:09Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![UsineLogicielle](https://avatars.discourse-cdn.com/v4/letter/u/f04885/32.png) [@UsineLogicielle](https://forum.gitlab.com/u/UsineLogicielle)\
**Post date:** [May 12, 2023, 1:41pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/1 "2023-05-12T13:41:09Z")

</div>

I’m running Gitlab v15.7.5 on a CentOS7 VM with 4cpus and 4Go of RAM  
Every night we run a cron to make a backup of our Gitlab instance.

The command we use is the following :

```auto
gitlab-rake gitlab:backup:create SKIP=registry,artifacts CRON=1

```

We use an ELK stack to monitor our VM and by using this command we observe a light spike at 1:00 AM which is the hour where the cron is triggered

 ![image](https://us1.discourse-cdn.com/gitlab/original/3X/5/8/58391de70386fe56accc9c28f33626b3aadeb46e.jpeg)

This command is fine for us, but we are aware that this one is deprecated like mentionned in this article : [Back up GitLab | GitLab](https://docs.gitlab.com/ee/raketasks/backup_gitlab.html) (Version 12.1 and earlier)

So we tried to switch on the new recommanded backup command for version 12.2 and after :

```auto
sudo gitlab-backup create

```

Unfortunately this command make our VM crash, and go full in every ressource (RAM,cpu,workload,SWAP) =\> This cause Gitlab to crash and the VM too :

 ![image](https://us1.discourse-cdn.com/gitlab/original/3X/b/c/bcbfee5705ef397bff218fe0a602b18feffa1f1b.png)

I tried to add the following parameter : GITLAB\_BACKUP\_MAX\_CONCURRENCY=1 but it didn’t work.

We went back to our previous backup process, but regarding the EOL of the previous command we have to find a way to make the new one successful. We have 2 questions :

- When will the old command (gitlab-rake backup ) will be disabled ?
- Is there anyone else who observed this behaviour with the new backup command ? What can I try to make it better ?

Thanks !

---

<div class="post-metadata">

**Author:** ![gitlab-greg](https://sea2.discourse-cdn.com/gitlab/user_avatar/forum.gitlab.com/gitlab-greg/32/6933_2.png) [@gitlab-greg](https://forum.gitlab.com/u/gitlab-greg)\
**Post date:** [May 12, 2023, 6:19pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/2 "2023-05-12T18:19:29Z")

</div>

There should be little or no difference in behavior, as `gitlab-backup create` is just a wrapper around `gitlab-rake gitlab:backup:create` ([omnibus-gitlab:config/templates/gitlab-rails/rake\_backup\_wrapper.erb](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/config/templates/gitlab-rails/rake_backup_wrapper.erb)) 🤔

Do you see the same behavor when running the `gitlab-backup create` command with the same options you used with `gitlab-rake gitlab:backup:create`?

```auto
sudo gitlab-backup create SKIP=registry,artifacts CRON=1

```

---

<div class="post-metadata">

**Author:** ![UsineLogicielle](https://avatars.discourse-cdn.com/v4/letter/u/f04885/32.png) [@UsineLogicielle](https://forum.gitlab.com/u/UsineLogicielle)\
**Post date:** [May 16, 2023, 12:28pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/3 "2023-05-16T12:28:45Z")

</div>

Thank you for your answer greg, we tried again with

```auto
sudo gitlab-backup create SKIP=registry,artifacts CRON=1

```

Unfortunately the result is the same, we just restored the VM and we are ready to investigate again. Any suggestion or hint is welcome from now on 🙂

---

<div class="post-metadata">

**Author:** ![UsineLogicielle](https://avatars.discourse-cdn.com/v4/letter/u/f04885/32.png) [@UsineLogicielle](https://forum.gitlab.com/u/UsineLogicielle)\
**Post date:** [May 17, 2023, 9:29am UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/4 "2023-05-17T09:29:31Z")

</div>

I got some new hints to work with.  
I’m going to try and play with those parameters in the gitlab.rb and update this post with my investigations

```auto
gitlab.rb
===================================
puma['per_worker_max_memory_mb'] = 2048
gitlab_rails['max_request_duration_seconds'] = 3600
puma['worker_timeout'] = 3601
puma['worker_processes'] = 8
gitlab_rails['env'] =
{ 'GITLAB_RAILS_RACK_TIMEOUT' => "3600", }

```

---

<div class="post-metadata">

**Author:** ![UsineLogicielle](https://avatars.discourse-cdn.com/v4/letter/u/f04885/32.png) [@UsineLogicielle](https://forum.gitlab.com/u/UsineLogicielle)\
**Post date:** [June 5, 2023, 1:03pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/5 "2023-06-05T13:03:18Z")

</div>

We found the solution to our problem  
We replaced the rake command with the gitlab-backup command in our cron backup script, but the gitlab-backup command call the gitlab-backup script in /bin/  
Problem is, this script is a symbolic link of our cron backup script in our environment, thus, made it a loop…  
Once the gitlab-backup script restored to the default one, and our cron-backup script moved somewhere else, everything worked as intended

---

<div class="post-metadata">

**Author:** ![bayardo.rivas](https://sea2.discourse-cdn.com/gitlab/user_avatar/forum.gitlab.com/bayardo.rivas/32/34342_2.png) [@bayardo.rivas](https://forum.gitlab.com/u/bayardo.rivas)\
**Post date:** [August 7, 2023, 1:44pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/6 "2023-08-07T13:44:01Z")

</div>

@UsineLogicielle and @gitlab-greg , I am starting to work with Gitlab and I would like to set up a cron to backup my Gitlab. What is the recomended command to do it?? Can I run the backup while it is working schedule?? Does the backup affect the developers work or pipelines??

Thanks in advance for your advice.

---

<div class="post-metadata">

**Author:** ![gitlab-greg](https://sea2.discourse-cdn.com/gitlab/user_avatar/forum.gitlab.com/gitlab-greg/32/6933_2.png) [@gitlab-greg](https://forum.gitlab.com/u/gitlab-greg)\
**Post date:** [August 18, 2023, 8:58pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/7 "2023-08-18T20:58:55Z")

</div>

Hi @bayardo.rivas 👋

I think you’ll find our documentation helpful and relevant: [Back up GitLab | GitLab](https://docs.gitlab.com/ee/administration/backup_restore/backup_gitlab.html). It includes [an example of how one can configure `cron` to make daily backups](https://docs.gitlab.com/ee/administration/backup_restore/backup_gitlab.html#configuring-cron-to-make-daily-backups).

> Can I run the backup while it is working schedule??

I suggest taking backups during off-hours if at all possible.

You _can_ back up GitLab data while people are actively using GitLab without issue, taking backups while data on the server is actively changing carries could result in losing some work if you have to restore. If you have to take backups of a GitLab instance that’s actively being used, I suggest exploring [options to scale or optimize backups](https://docs.gitlab.com/ee/administration/backup_restore/backup_gitlab.html#scaling-backups).

> Does the backup affect the developers work or pipelines??

The backup command consumes minimal system resources (CPU/RAM) and running it will not impact the usability of GitLab. Just make sure you have storage available for the backups if you’re storing backups locally on the same drive that GitLab uses for storage).

---

<div class="post-metadata">

**Author:** ![bayardo.rivas](https://sea2.discourse-cdn.com/gitlab/user_avatar/forum.gitlab.com/bayardo.rivas/32/34342_2.png) [@bayardo.rivas](https://forum.gitlab.com/u/bayardo.rivas)\
**Post date:** [August 21, 2023, 10:05pm UTC](https://forum.gitlab.com/t/gitlab-rake-gitlabcreate-vs-gitlab-backup/86364/8 "2023-08-21T22:05:47Z")

</div>

Thanks for your answer @gitlab-greg .