[ovirt-users] Re: Backup to tape

Hi, thanks for the links. We'll check. We already have snapshoting at the iSCSI storage array level (Compellent), together with replication between storage arrays. We have online a rolling 7 days snapshots + replicats. Of course, these are inconsistent snapshots. But from the numerous tests we've done during the past 10 years (in the context of Oracle VM) we never ever bumped into a VM that would not restart from what is a crash, from the VM point of view. If it occurs, we can try with the day before . We have online a rolling 7 days snapshots + replicats. Of course we'll consider synchronising oVirt snapshots with Storage replication and snapshot. Mounting a storage array snapshot and pipe dd over ssh to restore a VM is not a big deal and we don't feel the need of an additional product for that. I've tested the following : - Activate source and destination partitions Source : lvchange -ay 337efd74-b261-4855-b78c-5b28943df889/a01f9f37-9fe9-43b4-88e6-c2eb9470295e Destination : lvchange -ay 337efd74-b261-4855-b78c-5b28943df889/a01f9f37-9fe9-43b4-88e6-c2eb9470295e - Restore the partition dd if=/dev/337efd74-b261-4855-b78c-5b28943df889/a01f9f37-9fe9-43b4-88e6-c2eb9470295e bs=1M | ssh 192.168.235.218 dd of=/dev/337efd74-b261-4855-b78c-5b28943df889/a01f9f37-9fe9-43b4-88e6-c2eb9470295e bs=1M status=progress conv=sparse - deactivate the destination lvchange -an 337efd74-b261-4855-b78c-5b28943df889/a01f9f37-9fe9-43b4-88e6-c2eb9470295e Part of Disater Recovery Plan, we also need offline backups, to tape. Up to now we weekly tar the img files, taken from a storage array snapshot, to a LTO, and voila. Now Working with LVM partition, dd seems appropriate, except that we are loosing granularity. We'll backup everything and it'll take more time. I've tested the following and it seems OK to backup to tape an entire iSCSI LUN dd if=/dev/mapper/36000d310012f4a00000000000000021d of=/dev/nst0 bs=1M status=progress I was just wondering if conv=sparse at the device level (iSCSI LUN) may break things or not.