[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Questions about a script for regular backups

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 22 Aug 2019 09:38:02 -0400

On Thu, Aug 22, 2019 at 9:16 AM Anton Shepelev <anton.txt_at_gmail.com> wrote:

> [Having failed to post this message via Gmane, I am sending it by e-mail]
>
> Hello, all
>
> In order to write a backup script in the Windows batch
> language, I was reading the section "Migrating Repository
> Data Elsewhere" from "Repository Maintenance":
>
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html
>
> where I found the following interesting paragraph:
>
> Another neat trick you can perform with this
> --incremental option involves appending to an existing
> dump file a new range of dumped revisions. For example,
> you might have a post-commit hook that simply appends the
> repository dump of the single revision that triggered the
> hook. Or you might have a script that runs nightly to
> append dump file data for all the revisions that were
> added to the repository since the last time the script
> ran. Used like this, svnadmin dump can be one way to back
> up changes to your repository over time in case of a
> system crash or some other catastrophic event.
>
> The book unfortunately does not seem to give any examples of
> this usage, leaving the following questions:
>
> 1. Is "appending" to be understood literally, that is
> using the >> operator on a previously existing dump
> file, or is it a figure of speach describing a
> supplementary dump file that shall be applied "on top"
> of a previous one?
>
> 2. How does one determine the revision range for a
> routine incremental dump -- by calling
> `svnlook youngest' before dumping?
>
> 3. Must the backup script somehow store the last revision
> in the dump between calls? If so, I shall have to
> keep in a file and not let anybody touch it.
>
>
My first choice option would be to setup a repository on a second server
and use svnsync from a post-commit hook script to sync the change. After
that, I would use svnadmin hotcopy with the new --incremental option (as of
1.8?). Dump is not a great choice for backups.

The main advantage of svnsync is you can push the change via HTTP or SVN to
a different system where as hotcopy needs FS access so the only way to get
the repos on to a second server is if you can mount the FS via NFS or
something.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2019-08-22 15:38:30 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.