On 3 February 2016 at 16:32, Sam Yaple <sam...@yaple.net> wrote: > > Looking into it, however, shows Cinder has no mechanism to delete backups > in the middle of a chain since you use dependent backups (please correct me > if I am wrong here). This means after a number of incremental backups you > _must_ take another full to ensure the chain doesn't get to long. That is a > problem Ekko is purposing to solve as well. Full backups are costly in > terms of IO, storage, bandwidth and time. A full backup being required in a > backup plan is a big problem for backups when we talk about volumes that > are terabytes large. >
You're right that this is an issue currently. Cinder actually has enough info in theory to be able to trivially squash backups to be able to break the chain, it's only a bit of metadata ref counting and juggling, however nobody has yet written the code. > Luckily, digging into it it appears cinder already has all the > infrastructure in place to handle what we had talked about in a separate > email thread Duncan. It is very possible Ekko can leverage the existing > features to do it's backup with no change from Cinder. This isn't the > initial priority for Ekko though, but it is good information to have. Thank > you for your comments! > Always interested in better ways to solve backup. -- Duncan Thomas
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
