On Sun, 27 Sep 2015, Anton Aylward wrote:
On 09/27/2015 03:53 AM, Linda Walsh wrote:
--- ??? You lost me on this one. W/a backup, you usually concatenate all of the files -- so it doesn't matter if the block size of the source is 512b or 4k, the only thing backed up is actual size of the data (or less if you still use compression). So the really, wouldn't matter if you went to a 1MB block size WRT backups, as the backups only store the original data -- not the 'slack'.
Linda, you've made a generalization that isn't valid.
Not everyone uses the same backup strategy.
That doesn't mean every backup strategy is just as sound. Some have serious deficiencies that others call perks. And most of it revolves around not needing high-level or sophisticated tools. See, in Linux it is often easier to build a weak system on existing tools that seem to do the job, than it is to really build something good but that would require more development. This tendency to reuse what exist and to end up with a solution with the minimal amount of effort is what produces such bad designs all the time. It is not designed based on beauty, but just on economy.
Some tape methods preserve the gaps in the file. Its one thing to dump your database to text file, a series of SQL statements, and back that up, but some people quite literally back up the database.
I guess it would be easier. Backing up the dump might require additional scripting that you do not have in place yet.
For example, if I back up /var/lib so as to preserve a lot of dynamic configuration and settings (such as DNS, DHCP, the Yast/zypper databases) I also back up the MySQL files, which are also "sparse".
Some are literally sparse: unassigned blocks. Some have fixed sized fields that are not full. It doesn't matter.
Does that mean those sparse files are 'registered' on disk as being, like, huge, while their actual space requirement is very slim, but if you were to put it in a tar file it would suddenly take up all that "real space"?.
You can argue that there are modes of backing up that convert this to actual space, which is why you should dump files and backup the dump. But there are backup tools like rsync which honour the preserve the sparseness.
The funny thing is of course that if you compress it it will also become sparse, but in that case you wouldn't be able to restore the sparse file on restoration.
It depends on the user and the backup strategy.
We've long since established that not everyone runs their system the way you do, Linda. Please don't assume your way is the only way.
She's not saying it is the only way. She is just saying that from a design perspective, it makes much more sense. The choices for these other schemes basically comes down to cheapness. Reusing the filesystem as a database means you don't have to write your own or do your own coding around that. I call it abuse really. There is a well available script that does incremental rsync like I said to another volume or even remotely and keeps a roll of backups in different directories based on hard-links to the first backup (or whatever, hardlinks are really relative). It probably works perfectly except that you might have millions of files and each backup adds a whole bunch of hardlinks. So the filesystem is used as the database for the backup. It is very easy and fast to write such a thing, which is why it is being done. But that doesn't mean it is sound or well thought out. It is just fast to code. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org