On 09/27/2015 03:53 AM, Linda Walsh wrote:
Felix Miata wrote:
It's a seriously good thing storage densities continue to rise, and unit cost continues downward, but they don't necessarily interplay nicely with smaller sizing paradigms WRT backup strategies, or size limitations of backup media.
--- ??? 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. Yes, if your backup is to convert all the files into a tarball and write that out to long term media, you are correct. There are few analogues to tarballing as well. But some people simply do disk to disk and archive the disk. 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. 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. 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. 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. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org