I can think of very few cases where one would want the CONTENTS of swap or dump to be backed up, but I would likely want the layout backed up, so that (empty) volumes of the same size would be restored, leaving the restored system entirely ready to use.
Upside: faster, smaller, safer (information that would normally only be in RAM will be in those; unless you REALLY want the possibility of unlimited forensic snooping, or if you have some confidentiality rules to follow, you probably DO NOT WANT THAT) Downside: in exceptional use cases, one might want exactly what one normally would NOT want Anyway, the dump volume is strictly a place for it to be easy for a crashing OS to leave a dump image. The contents are usually saved (default to the /var/crash directory) when it boots again (allowing the dump volume to be reused for the next crash dump while preserving the contents). So the contents probably aren't useful between saving and the next crash anyway. The one case where one wants EVERYTHING (live migrating a running system) is a very managed thing to make it possible, and typically requires storage that is addressable by both source and destination systems (not actually copied at all, making it quick - otherwise TCP connections would time out, etc), and VLANs so addresses appear unchanged, etc; also management software to convey the configuration being transferred (e.g. this applies to LDOMs or kernel zones that are managed by the relevant commands). That is entirely different from backups. > On May 12, 2022, at 07:59, hput via openindiana-discuss > <[email protected]> wrote: > > Off hand it seems to not be important for a replication backup to > include. Only if there has been a crash dump of concern. Even then > still seems unneccesary for job of recreating a healthy OS from > backup. Still it is really not much data. In my case its reported > 6.64 GB, so might as well include in a replication backup eh? _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
