Re: svn hotcopy incremental overwrites existing revisions in backup

On Tue, May 16, 2017 at 10:57:44AM -0700, lumi wrote:
> Size mismatch is definitly takes place. Actual size is normal, but size on
> disk is a bit unreal, again because of deduplication.
> <http://subversion.1072662.n5.nabble.com/file/n198986/FileSize.png>

The whole point of a hotcopy is to have a 1-to-1 bit-identical backup.
If the NTFS filesystem which stores the backup is de-duplicating files
in a way that makes their filesize change, then incremental hotcopy
cannot work. By design, incremental hotcopy compares the size and
timestamp to see if a revision file must be copied again.
So if you really want to use svnadmin hotcopy you should disable the
de-duplication feature on the target filesystem.

But there are other tools you could use for backup purposes instead,
such as svnadmin dump/load and svnsync (e.g. with file:// URLs).
These should work fine with NTFS de-duplication enabled on backup storage.
See http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
and http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
Received on 2017-05-16 20:11:29 CEST