Last updated
Last updated
Helmut4 features a dedicated Docker container named 'mongobackup,' designed to generate a comprehensive backup of the configuration, i.e., the database. This backup process is scheduled using a cron timer.
A predefined number of backups, such as 60, will be retained. When the container attempts to create the 61st backup, it will automatically remove the oldest backup to maintain the specified limit.
In the event of a fatal error, the Helmut4 configuration can be restored promptly within a few minutes.
It's advisable to choose a backup path directed towards a network share rather than the local host. This precaution is important because, in the event of a host crash, relying solely on local backups could lead to data loss.
Additionally, we suggest saving the backups to a folder with appropriate access rights. This ensures that the backups are safeguarded from accidental deletion by unauthorized users.
Please create a new folder titled 'backup' on your designated target destination.
It's crucial to verify that the host possesses adequate read and write permissions for optimal functionality.
Example folder path: /mnt/demo-h4/backup
Navigate Portainer, which runs on port 9000 and log in:
Portainer web GUI http://ip-helmutserver:9000
Further informations about Portainer / login navigate to
To add a volume to the 'mongobackup' container, follow these steps:
click on “primary”
click on “stacks”
click on “helmut4”
click on the tab “Editor"
Locate the following service 'mongobackup' and adjust the volume entry accordingly:
Example folder path: /mnt/demo-h4/backup
It's crucial to note that the target should be explicitly defined as /backup on the right side, rather than /Volumes/demo-h4/backup.
Not following this guideline could lead to issues with the automated backup process.
If we consider to take this cron, the 'mongobackup' configuration would look like this:
The number of backups can be configured using the key for the value "MAX_BACKUPS."
Setting this to 180 means that this specific quantity of backups will be retained. Subsequent backup processes will generate a new backup (number 181) and, upon completion, delete the oldest backup instance, ensuring that the total count remains at 180.
Please keep in mind that the number of backups and their intervals will directly impact your retention period.
The size of backups will gradually increase over time, as they are associated with the number of projects, assets, and jobs in your database.
Size of one backup: 500mb
Max Backups: 180
Cron: every hour
180 (backups) / 24 (hours a day) = 7,5 days
180 (backups) * 500mb / 1000 (mb to gb) = 90GB
Size of one backup: 500mb
Max Backups: 180
Cron: every 4 hours
180 (backups) / 6 (one sixth of a day) = 30 days
180 (backups) * 500mb / 1000 (mb to gb) = 90GB
Size of one backup: 500mb
Max Backups: 90
Cron: every 4 hours
90 (backups) / 6 (one sixth of a day) = 15 days
90 (backups) * 500mb / 1000 (mb to gb) = 45GB
Every time mongobackup is restarted, it will generate a new (unscheduled) backup.
General informations about this task can be found here:
To familiarize yourself with cron, please head to , which provides a user-friendly GUI for setting up a cron.
Defining a cron time is a straightforward task. For instance, if a is intended to run every Saturday at 4:30, the corresponding cron expression would be: 30 4 * * SAT
.
The visual reference below describes the .