Add a New Comment (Rich Markup)
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
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? -LenW
(Please forgive my formatting screw-ups; that was my first Savannah post.) -Len
==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 precautions.
The import processing would be very similar to the ordinary backup done in bin/storeBackup, with some important differences:
include/exclude, and walking the directory tree, just read the primary .md5Checksum and .md5BlockChecksum files.
files, and exists in the primary backupDir tree, so no new splitting nor compression needs to be done.
information needed to make this decision is in the Checksum files, including the MD5 sum.
remains as it was, pointing to the original data, but the inodeBackup field is for the newly imported secondary backup.
so it does not need even to be available.
as the primary backup. The secondary .info and log files could hold the information tracing the history of this backup.
equivalent. Each stands on its own for use in restores, further importation, or even sharing files with a new backup.
intact and has not been subject to manual changes.
to bin/storeBackup.
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
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 2 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11