doc/administration/get_started.md
{{< details >}}
{{< /details >}}
Get started with GitLab administration. Configure your organization and its authentication, then secure, monitor, and back up GitLab.
Authentication is the first step in making your installation secure.
Organize your environment by configuring your groups and projects.
<i class="fa-youtube-play" aria-hidden="true"></i> Watch an overview of groups and projects.
Get started:
More resources
You might have to import projects from external sources like GitHub, Bitbucket, or another instance of GitLab. Many external sources can be imported into GitLab.
For assistance with these data types, contact your GitLab account manager or GitLab Support about our professional migration services.
Security is an important part of the onboarding process. Securing your instance protects your work and your organization.
While this isn't an exhaustive list, following these steps gives you a solid start for securing your instance.
After you've established your basic setup, you're ready to review the GitLab monitoring services. Prometheus is our core performance monitoring tool. Unlike other monitoring solutions (for example, Zabbix or New Relic), Prometheus is tightly integrated with GitLab and has extensive community support.
GitLab provides backup methods to keep your data safe and recoverable.
The routine differs, depending on whether you deployed with the Linux package or the Helm chart.
To back up a single-node installation that uses the Linux package, you can use a single Rake task.
Learn about backing up Linux package or Helm variations. This process backs up your entire instance, but does not back up the configuration files. Ensure those are backed up separately. Keep your configuration files and backup archives in a separate location to ensure the encryption keys are not kept with the encrypted data.
You can restore a backup only to the exact same version and type (Community Edition or Enterprise Edition) of GitLab on which it was created.
In some situations the Rake task for backups might not be the most optimal solution. Here are some alternatives to consider if the Rake task does not work for you.
If your GitLab server contains a lot of Git repository data, you might find the GitLab backup script to be too slow. It can be especially slow when backing up to an offsite location.
Slowness typically starts at a Git repository data size of around 200 GB. In this case, you might consider using file system snapshots as part of your backup strategy. For example, consider a GitLab server with the following components:
/var/opt/gitlab.The EC2 instance meets the requirements for an application data backup by taking an EBS snapshot. The backup includes all repositories, uploads, and PostgreSQL data.
If you're running GitLab on a virtualized server, you can create VM snapshots of the entire GitLab server. It is common for a VM snapshot to require you to power down the server.
{{< details >}}
{{< /details >}}
Geo provides local, read-only instances of your GitLab instances.
While GitLab Geo helps remote teams work more efficiently by using a local GitLab node, it can also be used as a disaster recovery solution. Learn more about using Geo as a disaster recovery solution.
Geo replicates your database, your Git repositories, and a few other assets. Learn more about the data types Geo replicates.
GitLab provides support for GitLab Self-Managed through different channels.
To get help:
Rate limits prevent denial-of-service or brute-force attacks. In most cases, you can reduce the load on your application and infrastructure by limiting the rate of requests from a single IP address.
Rate limits also improve the security of your application.
You can make changes to your default rate limits from the Admin area. For more information about configuration, see the Admin area page.
For more information about API and rate limits, see our API page.
You can learn more about how to administer GitLab.