Comment by tinus_hn
3 years ago
Obviously to know what to restore, you need to index the data on the tapes. Tape is not a random access medium, there is no way around this.
This is only for a complete disaster scenario, if you’re restoring one PC or one file, you would still have the backup server and the database. But if you don’t, you need to run the command to reconstruct the database.
There is a way around this: You allocate enough space at the beginning (or the end, or both) of the tape for a catalog. There are gigabytes on these tapes; they could have reserved enough space to store millions of filenames and indices.
Then you would have to rewind the tape at the end, which is not what you want. You want to write the tape and keep it at that position and be done.
If you write the catalog at the end, you have to rewind and read the whole tape to find it and read it. Which is not an improvement over reading the tape and reconstructing it.
This is all either impossible or very difficult to fix when there is actually not a problem, if there is a disaster and the database is lost, you just read the tapes to reconstruct it.
If the catalog was at the start of the tape, how would you expand it when adding more files to the tape?
And if the catalog was at the end of the tape, how would you add more files at all?
> And if the catalog was at the end of the tape, how would you add more files at all?
modern zip softwares just remove the whole index at end, add file, reconstruct the index and append again.
3 replies →
Put it in the middle and work your way in from the ends!
There are lots of append-only data structures that would support this, but would also require scanning the tape to reconstruct the catalog.
1 reply →
Beginning: write more entries into the allocated space I mentioned. End: write more entries into the allocated space I mentioned.