Tag Archive for 'backup'

Backing Up Your SmartSVN Data

No matter how experienced you are with Apache Subversion, accidents and unavoidable occurrences happen, so it’s important to make repository data backups. If you’re using SmartSVN, the cross-platform graphical client for Subversion, the built-in ‘Export Backup’ functionality makes it quick and easy to create a backup of a selected file/directory.

To backup your data in SmartSVN:

1) Highlight the file(s)/directory to backup, and select the ‘Export’ option from SmartSVN’s ‘Query’ menu.

2) In the subsequent ‘Export Backup’ dialog, you’ll be presented with several options:

  • ‘Relative To’ – the common root of all files to be exported

  • Into zip-file/Into directory – select how you want to export your data. In both cases, you must specify the location where the backup will be created

  • Include Ignored Files – files marked as ‘ignored’ will not be included in the backup

  • Include Ignored Directories – note, this option includes all the items in the ignored directories

  • Wipe directory before copying – wipe the selected directory before performing your backup

export backup

Depending on the selection of files or directories, the ‘Export’ option will either display the number of files being exported or a ‘All files and directories’ message.

3) Once you are satisfied with the information you have entered, click ‘Export’ to create your backup.

Want more free Subversion training? We offer plenty of webinar replays available on-demand, or you can sign up for our upcoming webinars.

Subversion Tip of the Week

Backing up Your Subversion Data

No matter how clued up you are on Apache Subversion, disasters do happen, so it’s important to make regular backups of your repository data. There are several options for creating a backup:

1) Incremental backup – creates a copy of all the changes that occurred since the last backup. To perform an incremental backup, you must specify a “starting_revision” revision number:

svnadmin dump {repository} -r {starting_revision} -incremental.

This creates a dump file with information about the revisions that took place between the “starting_revision” and the latest revision.

2) Full Backup – this is essentially a copy of the entire repository, and it can be performed by running the following command:

svnadmin hotcopy {repository} {destination}

Alternatively, a full dump can be performed using the ‘hot backup’ script located in the tools/backup directory:

The hot-backup.py {repository} {destination}

3) Backing up with SmartSVN

If you’re using SmartSVN, the popular, cross-platform graphical client, the built-in ‘Export Backup’ functionality makes it quick and easy to create a backup of your files and directories.

1) To create a backup, select the ‘Export’ option from the ‘Query’ menu. This will open the ‘Export Backup’ dialog.

In this dialog, ‘Relative To’ is the common root of all files to be exported. Depending on the selection of files or directories, the ‘Export’ option will either display the number of files being exported or a ‘All files and directories’ message.

2) You can choose to export into either ‘zip-file’ or ‘Into directory.’ In both instances, you must specify the location where the backup will be created.

3) Optionally, you can decide to ‘Include Ignored files’ and ‘Include Ignored Directories.’ Note, the second option includes all the items in the ignored directories.

4) Once you are happy with the information you have entered, click ‘Export’ to create your backup.

Remember, you can claim your 30 day free trial of SmartSVN Professional now.

 

9 Ways to Dominate Development with Jenkins

Last month, we were proud to co-host another free training webinar with our friends at CloudBees. ‘9 Ways to Dominate Development with Jenkins’ was presented by WANdisco’s Director of Training, Mike Lester, and CloudBees’ Elite Developer and Architect, Ryan Campbell. Mike covered the essentials of setting up Jenkins through uberSVN, the free, open ALM platform for Apache Subversion, before CloudBees’ Ryan Campbell shared a grand total of nine best practices for using Jenkins with uberSVN.

The tips included how best to backup the Jenkins continuous integration server. Webinar attendees were shown how to locate their configuration data in the $JENKINS_HOME directory. The location of this directory varies depending on how you install Jenkins, but in uberSVN you can check this using the Configure Systems screen. To access this screen, simply click on ‘Manage Jenkins’ in the Jenkins tab of uberSVN.

From here, select the ‘Configure Systems’ option.

This will take you to the all-important Jenkins Home directory, which contains the data you will need to backup.

Webinar attendees also learnt that it’s possible to create a backup while Jenkins is running, as Jenkins makes changes atomically to the cloud system. Whenever you change your configuration, Jenkins writes that configuration file to a temporary file and then moves it over atomically at the operating system level, which means creating a backup of a live Jenkins installation isn’t a problem.

The webinar also shared advice for planning disk capacity for Jenkins, the benefits of native installers, adding additional distributed builds to your Jenkins instance, and more.

Missed the webinar the first time around? The good news is that the entire webinar replay is now available to view on-demand, from our Webinar Replay page. And, if you enjoyed ‘9 Ways to Dominate Development with Jenkins,’ you can sign up for more of our upcoming webinars at http://www.wandisco.com/training/webinars.

How to Backup Subversion Repositories

No matter how clued up you are on Subversion, disasters do happen, so it’s important to make backups of your repository data. There are two major issues to bear in mind, when creating your backups:

1) You are making a copy of a live repository – if another developer makes a change to the repository during backup, it could result in the backup missing data, or being corrupt. This can be avoided either by restricting access to the Subversion server while the backup is being performed, or performing a hot copy.
2) Unversioned revision properties can cause problems – for example, modifications to unversioned properties will not trigger any post-commit hooks you have in place.

There are two options available to Subversion developers: an incremental backup, or a full backup.

Incremental backup

An incremental backup makes a copy of all the changes that occurred since the last backup. To perform an incremental backup, you must specify a “starting_revision” revision number:

svnadmin dump {repository} -r {starting_revision} -incremental.

This creates a dump file with information about the revisions that took place between the “starting_revision” and the latest revision. This file can then be loaded into Subversion, following any data loss.

Full Backup

A full backup of a repository is essentially a copy of the entire repository, and it can be created in several ways. You could use:

svnadmin hotcopy {repository} {destination}

This command will create a local directory containing a complete copy of the repository, including hooks, configuration files and database files, while compensating for anyone who may be writing to the directory at the same time. The –clean-logs switch can optionally be used to clear up any unused Berkeley DB logs in the original repository.

Alternatively, a full dump can be performed using the ‘hot backup’ script located in the tools/backup directory:

The hot-backup.py {repository} {destination}

Once the repository and backup locations are entered, this script backs up the repository without requiring the administrator to temporarily restrict access to the repository. The script can also be added to a program scheduler, or post-commit hooks can optionally be set to call hot-backup.py, which will automatically backup the repository whenever a new revision is created.

Some alternative solutions for creating a full backup, include:

  • svnadmin dump – creates a dump file of the content of an entire repository. This dump file can then be loaded into a new repository (using ‘svnadmin load’) as required.
  • svnsync – creates and maintains a read-only mirror of your repository, by relaying commits that occur in one repository, and committing them into another. svnsync can be used to create a duplicate of any repository to which you have read access.

The key benefit of a full backup, is the creation of a functional Subversion repository that can be used as a drop-in replacement. On the downside, if you are maintaining multiple full backups of a repository, then disk space could be an issue, which encourages infrequent backups – a potentially risky strategy if you suffer data loss just before a scheduled backup! Of course, it’s also possible to mix both solutions, to suit your particular needs; for example, some teams perform a full dump at defined intervals, and intersperse them with frequent incremental backups. There is also the option of supplementing your backups with additional solutions, such as an archive of all the commit and property change notification emails, which can be a useful resource when disaster strikes.

Subversion Tip of the Week

Backing up Apache Subversion

No matter how clued up you are on Apache Subversion, disasters do happen, so it’s important to make backups of your repository data. In Subversion, there are two main ways to make a backup of your repository:

1) Incremental backup – makes a copy of all the changes that occurred since the last backup. To create an incremental backup, run the following command:

svnadmin dump {repository} -r {starting_revision} -incremental.

This command creates a dump file with information about the revisions that took place between the “starting_revision” and the latest revision, which can then be loaded following any unexpected data loss.

2) Full backup – this essentially creates a copy of an entire repository. It can be created in two ways:

svnadmin hotcopy {repository}{destination}

This command will create a local directory containing a complete copy of the repository, including hooks, configuration files and database files.

Alternatively, you can use the ‘hot backup’ script located in the tools/backup directory:

hot-backup.py {repository}{destination}

How to Cut Development Time in Half, Improve Build Performance by 500% and Eliminate Downtime

SSP, a leader in software applications for insurance and financial services, with developers in the UK, Australia and South Africa did it by implementing Subversion WAN Clustering (MultiSite) .  As soon as developers at one site commit changes they’re available everywhere at LAN-speed. SSP’s developers in the UK, Australia and South Africa checkout and commit changes to the same files simultaneously and have immediate access to each other’s work.  Merge conflicts and other problems that weren’t discovered for days or weeks until it was time to create a build, are caught and fixed when they happen.  The best talent for a project regardless of location can work together as one agile, virtual development team to get the job done faster.  The net result is that the time SSP has to spend on QA and rework has gone down so dramatically that development cycles have been cut in half.

Now that every developer has instant access to the latest changes regardless of where they came from, builds can be created and tested at each site in less than a day, instead of waiting up to 5 days for a central team to complete their development work and schedule in builds for other sites.

SSP has also been able to go 24-by-7 with no downtime because Subversion WAN Clustering has turned their distributed Subversion servers into mirrors of each other. When one server goes down for either a planned or unplanned outage, users failover to another site and keep working. When a server comes back online it recovers automatically, grabbing all of the changes that happened at other sites while it was offline.

Get SSP’s full story to learn more about how all of this was accomplished.

avatar

About Jim Campigli