Announcement

Collapse
No announcement yet.

"svnadmin verify" and backup solution.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • "svnadmin verify" and backup solution.

    Hi all;

    I am looking at automating backups on repos, and in order to do that the procedure should somewhat follow the bellow guidelines:

    1) svnadmin verify ... : Used to verify integrity of the repo.
    2) svnadmin dump .... : Used to create a single backup file of the entire repo.
    3) backing up the dump file: saving the dump file somewhere else for recovery purpose.
    4) svnadmin load ... : In case the repo has been damaged it can be restored from the latest dump file.


    1) What step does "svnadmin verify" command take in order to verify the integrity of the repository? For instance, if a bad sector on the drive or memory corruption affect elements of the repository, how is this going to be dealt with by the verify procedure to detect such error/fault has occured?

    2) If "svnadmin verify" is indeed capable to detect such issues, then would it make sense, and if so is it safe, to backup dumped repo file on a rotation scheme, such as full backup followed by incremental one, and repeat this operation on a regular basis. Doing so would require a huge amount of space, so discarding older backups would make sense.
    This will have repercution if "svnadmin verify" is not able to detect corruption due to hardware failure as rotation scheme would carry over corrupted files within the repo.

    Can someone shade the light on the subject?

  • #2
    I don't think svnadmin verify can specifically detect and diagnose hardware issues ; if a disk is corrupt, svnadmin will not be able to read the rev file properly and report the error and fail - I haven't encountered such a scenario, but if you use the exit codes to perform the backup and delete old backup, this can be automated. Svnadmin verify checks the internal references of each revision file to previous revisions and it's contents using md5 hashes. Say changes to file A in rev 123 itself have a md5sum , and the resultant full file A md5sum as x , then it stores that md5sum in rev 123 file (along with any other files changed in that commit ). Then it goes on to check higher revisions , say 130 - when file A changed again, it seems to check if the current file A matches the stored md5sum, if not, it reports errors like this :

    svnadmin: Corrupt node-revision '1-1575.0-2915.r7333/7301'
    svnadmin: Found malformed header in revision file

    svnadmin: Checksum mismatch while reading representation:
    expected: 2022c1f55888e27da5d24ac72cbeecd6
    actual: 2aa81479f25e5502bcd53e21566dbbcb

    However, I don't think svnadmin verify is foolproof, you may still have integrity issues which verify does not report (and this may not be a problem ,if your checked out data is correct ).

    Comment


    • #3
      Hi RahulP;

      Thanks for the comment. If checksum is indeed used on every files within the repo, then I don't see any particular issue with running rotation backups.
      Can you provide a reference/source to the information you provided? and which step did you take to emulate the failure?

      Comment

      Working...
      X