mainstoreBackup - Support: sr #107107, new functionality request: ...


sr #107107: new functionality request: import a backup from one backupDir into another

Submitter:  Len Weisberg <lenw>
Submitted:  Thu 05 Nov 2009 12:24:32 AM UTC
Category:  None Priority:  5 - Normal
Severity:  1 - Wish Status:  Ready For Test
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup

Thu 31 May 2012 08:40:11 PM UTC, comment #3: 

Beside others, next version (3.3) will support replication of selectable backup series to one or more other disks.

It's working for me since three weeks, but I still have to write the documentation :-( .

If you want to test it, please write an email to me.

Regards, Heinz-Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Thu 04 Aug 2011 09:44:18 PM UTC, comment #2: 

It's been a long time since I posted this, but I'm still
interested in this functionality.
Do you have any thoughts about it?

Len Weisberg <lenw>
Thu 05 Nov 2009 12:29:46 AM UTC, comment #1: 

(Please forgive my formatting screw-ups; that was my first Savannah post.)

Len Weisberg <lenw>
Thu 05 Nov 2009 12:24:32 AM UTC, original submission:  

==Overview: ==

  Having multiple physical copies of a backup is a big security win,
  especially if it allows backups to be kept off-site.
  It seems that a fairly minor variant of the storeBackup process could
  provide a streamlined and very fast way of producing such multiple copies.
  I think it best to think of it as importing a backup from one backupDir
  to another, since it is not necessary for the entire backupDirs
  to be identical.

  The key to the streamlining is to note that the resource-intensive
  activities, namely computing MD5 sums and compressing files,
  have already been done when the "primary" backup was produced, and
  would not have to be done again when the backup is imported into the
  "secondary" backupDir.  You would not even have to split large files
  into blocks nor walk the directory tree.

  Furthermore, the import process does not involve the original data tree.
  So even if access to the original data is suspended during the creation of
  the primary backup, the secondary backup could be produced without those

A brief outline of the program logic:

 The import processing would be very similar to the ordinary backup done
 in bin/storeBackup, with some important differences:

  1. Generate the DBM databases as usual.

  1. In the streamlined case, instead of figuring out what files to

   include/exclude, and walking the directory tree,
   just read the primary .md5Checksum and .md5BlockChecksum files.

  1. Use the compression and/or blocking as is listed in the Checksum

   files, and exists in the primary backupDir tree, so no new
   splitting nor compression needs to be done.

  1. Hard-link or copy each file or block, as usual, but all the

   information needed to make this decision is in the Checksum files,
   including the MD5 sum.

  1. In the new, secondary .md5Checksum file, the dev-inode field

   remains as it was, pointing to the original data, but the
   inodeBackup field is for the newly imported secondary backup.

Some notes:

  1. The original data tree is not used in this process,

   so it does not need even to be available. 

  1. The secondary backup should have the same time-stamp and name

   as the primary backup.  The secondary .info and log files could hold
   the information tracing the history of this backup.

  1. After the import, the primary and secondary backups are completely

   equivalent.  Each stands on its own for use in restores,
   further importation, or even sharing files with a new backup.

  1. This process strongly assumes that the primary backup is

   intact and has not been subject to manual changes.

  1. One possible implementation would be to add an0import option

   to bin/storeBackup. 

  1. Another would be to write a new bin/storeBackupImport program

   with much of the detail using the same lib/*.pl as the main program.
   A complete implementation could include logic for include/exclude
   and for deleting older backups, but I think it would be just fine
   to omit those features from the first (streamlined) version.

   (Which would be better?)

What do you think about this idea?

(I marked the priority as a "Wish", but I would love to be able to
do this.)

Thanks for your attention, and for a terrific backup facility.

Len Weisberg <lenw>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by hjclaes (Posted a comment)
  • -email is unavailable- added by lenw (Submitted the item)
  • -email is unavailable- added by lenw

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-05-31 hjclaes StatusNone Ready For Test
    2009-11-05 lenw Carbon-Copy- Added lenw

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code