Hello, Le jeu. 22 août 2019 à 15:52, Anton Shepelev <anton....@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
