[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: Pierre Fourès <pierre.foures_at_gmail.com>
Date: Thu, 22 Aug 2019 16:33:36 +0200

Hello,

Le jeu. 22 août 2019 à 15:52, Anton Shepelev <anton.txt_at_gmail.com> a écrit :
>
> Andreas Stieger:
>
> >The dump format is not the best option for backups. The
> >restore time is much too slow as you need to recover from a
> >serialized format. In many hand-baked scripts the dump
> >method misses point-in-time recovery capabilities, ->
>
> >Just make sure you take a consistent snapshot, which can be
> >achieved by briefly locking it (svnadmin lock) or operating
> >on a consistent copy (svnadmin hotcopy).
>
> Is a hot-copy portable between SVN versions? How safe is it
> to rely on a hot copy instead of a dump?
>

Indeed, I've encountered the problem that of restoring dumps was way
too slow and I ended up with a "belt and suspenders" solution
consisting of doing hot-copies to guarantee timely restoration time
(on systems with same software configurations), but also dumps to
guarantee restoration (on systems where the software configurations
would differs). For one reason or an other, but mainly if I need to
upgrade subversion and a breaking change would occurs, if the
hot-copies restorations wouldn't work, I would admittedly screw up to
restore it timely, but I would be able to restore it eventually.
However, while I do hot-copies every night, I intended to do dumps
only on week-ends. Up to now, the systems (svn-master and the storage
solution) handle the extra load of doing both solution every night, so
I let it that way (but might reconsider it in the future).

Admittedly, this situation should be very unlikely, but I feel more at
ease to have took it into account. More over, I also set it up it in
the event to handle two use case situation : the first is to complete
timely restoration in case of emergencies, this is handled with
hot-copies ; the second is to handle server upgrades (with software
upgrades), this is handled with dumps. For this second use case,
clearly, this shouldn't be done in emergency situations, so the dump
solution fit fine in this use case while also ensuring (and being
designed for) smooths upgrades between distinct software revisions. Of
course, if not implemented in the backup solution, I would never have
a dump ready when required for a server upgrade. Having integrated it
in the nightly (or weekly) backups, I know I always have a fresh dump
ready for when I intend to upgrade my server. BTW, I talk here of
logical server (the https://svn.company.com/), not physical (or
virtual) instances. I usually never upgrades production running
server. I prefer to install the "upgraded one" from a fresh install
and take the opportunity to do a full restoration to double-check
everything is fine and recoverable. In this particular pursuit, I find
the dumps to be very valuable.

Best Regards,
Pierre
Received on 2019-08-22 16:34:15 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.