Hot answers tagged

40

There are many ways to do this but the easiest way I can think is doing a backup of the Jenkins Home folder. You can see where is your Jenkins home with: echo $JENKINS_HOME And for example, if you only want to backup the jobs you can go to: cd $JENKINS_HOME/jobs And make a backup for that folder. All that configuration will be a bunch of XML files. If ...


35

All jobs (jobs/) and master config files (config.xml) can be found in Jenkins home folder (JENKINS_HOME ) in the following structure: JENKINS_HOME +- config.xml (jenkins root configuration) +- *.xml (other site-wide configuration files) +- userContent (files in this directory will be served under your http://server/userContent/) +- ...


11

If your Jenkins jobs are defined in a Jenkinsfile you can store it in a git repository and have it loaded up by using Pipeline. Unfortunately, since not all Jenkins plugins support Jenkinsfile and Pipeline, you will need to manually create new Jenkinsfiles if you wish to move existing jobs to this format.


9

The SCM Sync Configuration Plugin does exactly what you wish. Works with either svn or git to backup your jenkins core and job configuration, so gives you easy tracking as to who made changes, as well as a backup.


7

Well that's not exactly about chef, you're basically asking how to use tar. The command to create an archive of a folder would be tar -zcvf <backup_thing>.tgz <path_to_backup> In the tar options: z pass the resulting tar archive to gzip for compression c instruct tar to compress (create the archive) v tells tar to be verbose, so you know at ...


5

There are few ways to backup jenkins data and master configurations. The best way for backup is to use the Thinbackup plugin. You can schedule timely backups using cron expressions. You can configure full backup and incremental backup as well. Another way to backup data and config is to take the disk snapshot of your jenkins master server. The ideal way to ...


4

Historically, I approached this a bit differently. I added a post-build step to each job, and had it copy the output to S3 at execution time via the S3 plugin. This blog post covers the moving parts n a pretty granular detail. You may want to reference wget -O console-output.log ${BUILD_URL}consoleText as the output for the job in question in your ...


3

You can try the thinBackup plugin (even though it is not actively maintained) [if taking a logical backup is all you want] (i.e. most of the config xml files, jobs, nodes etc). The backup size won't be huge.


3

I'm using scripts from sue445/jenkins-backup-script. It archives Jenkins settings and plugins such as: $JENKINS_HOME/*.xml $JENKINS_HOME/jobs/*/*.xml $JENKINS_HOME/nodes/* $JENKINS_HOME/plugins/*.jpi $JENKINS_HOME/secrets/* $JENKINS_HOME/users/* Usage ./jenkins-backup.sh /path/to/jenkins_home archive.tar.gz # add timestamp suffix ./jenkins-backup.sh /...


3

The things that would be backed up would be the config files of the servers, the database and uploaded content as these will almost always be unique and necessary. The containers, VMs, even the webapps would NOT be backed up as these should all be uniform and constantly updated under the CI/CD principles. Currently I use a combination of scp and tar into an ...


2

The biggest problem with database backups is that you cannot simply snapshot them. You first have to make sure the DB is not mid-transaction when taking a snapshot, otherwise you will restore to an inconsistent state. In the case of windows, you can leverage the Microsoft SQL VSS writer to snapshot your database. You will want to be sure that when you take a ...


2

You seem to be confused a bit about how Firestore stores data and what Google is suggesting you do. What is the problem? You are backing up a bucket inside other bucket. This is not correct. Firestore stores its data inside some sort of mostly opaque database format. If you are copying this out to a GCS bucket, that really is an export into a different ...


2

On top of protecting your root account as best as you can, you should be able to reduce the risk of such resource deletion if you have more than 1 resource to protect. For example if all AWS resources you had to protect were 2 RDS database servers, you could create 2 other accounts that have access to only copy the snapshots of one of your database servers ...


2

Corey's answer ended up inspiring me to take another look at the plugins available, this time considering anything that could be applied to jobs as a post-build step. I found AWS CloudWatch Logs Publisher Plugin, which is a post-build step that pushes your logs to CloudWatch. Not quite the destination we originally had in mind, but it worked for us. Easy ...


1

Coincidentally I had to do something very similar yesterday. This is the script I used: #!/bin/bash -e VAULT_NAME=... # put your Backup Vault name here for ARN in $(aws backup list-recovery-points-by-backup-vault --backup-vault-name "${​​​​​​​VAULT_NAME}​​​​​​​" --query 'RecoveryPoints[].RecoveryPointArn' --output text); do echo "...


1

As I see in Velero code (version: v.1.5.3), the backups can have the following phases: New FailedValidation InProgress Completed PartiallyFailed Failed Deleting see: https://github.com/vmware-tanzu/velero/blob/v1.5.3/pkg/apis/velero/v1/backup.go#L195 Restores have these phases: New FailedValidation InProgress Completed PartiallyFailed Failed see: https://...


1

While I haven't tried this, I suppose a solution would be to have a regular pipeline (this should work in either build or release pipelines) that would check out your repo (as it's default first step) then some scripted command that adds the desired remote and pushes to it. Some pitfalls I could see you running into: issues with the state of the agent work ...


1

All you need is a backup of the postgres database and the projects (to be safe but they should be rebuildable by pulling them again from your VCS in most cases). Exporting an ovf of you full vm is really an overkill IMHO. Copying the volumes (pgdata and projects) is by far the simplest solution (the one I actually use). You simply have to put the folders ...


1

First chef runs as often as you configure it to do. Second Chef is a configuration management system and not a crontab or an orchestration system. Use chef to configure cron (that can not be not an option, try to find out why this is not considered) for your backup using consul-template to retrieve the secret from vault. Don't use Chef to run the backups ...


1

In terms of S3, for increased durability, consider cross region replication as an option if you want to increase the durability. AWS also provides their AWS Backup service you might investigate. I'm not certain of any benefit to transferring large amounts of data for durability to another provider. You'll pay a lot more for transfer, and it won't be ...


1

I needed to migrate a Jenkins from one Windows Server instance to another. Finally I managed to do it like that: Stop the Jenkins service (if you can afford it) Copy the entire Jenkins folder (by default C:\Program Files x86\Jenkins) Paste onto the new instance Go inside the directory and run jenkins.exe install This will register the freshly pasted ...


Only top voted, non community-wiki answers of a minimum length are eligible