<div dir="ltr">Hi Chris, <div><br></div><div>Unless I overlooked something, I don't see Cinder or Ceph versions posted.</div><div><br></div><div>Feel free to just post the codenames but give us some inkling.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 23, 2018 at 3:26 PM, Chris Martin <span dir="ltr"><<a href="mailto:cmart@cyverse.org" target="_blank">cmart@cyverse.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I back up my volumes daily, using incremental backups to minimize<br>
network traffic and storage consumption. I want to periodically remove<br>
old backups, and during this pruning operation, avoid entering a state<br>
where a volume has no recent backups. Ceph RBD appears to support this<br>
workflow, but unfortunately, Cinder does not. I can only delete the<br>
*latest* backup of a given volume, and this precludes any reasonable<br>
way to prune backups. Here, I'll show you.<br>
<br>
Let's make three backups of the same volume:<br>
```<br>
openstack volume backup create --name backup-1 --force volume-foo<br>
openstack volume backup create --name backup-2 --force volume-foo<br>
openstack volume backup create --name backup-3 --force volume-foo<br>
```<br>
<br>
Cinder reports the following via `volume backup show`:<br>
- backup-1 is not an incremental backup, but backup-2 and backup-3 are<br>
(`is_incremental`).<br>
- All but the latest backup have dependent backups (`has_dependent_backups`).<br>
<br>
We take a backup every day, and after a week we're on backup-7. We<br>
want to start deleting older backups so that we don't keep<br>
accumulating backups forever! What happens when we try?<br>
<br>
```<br>
# openstack volume backup delete backup-1<br>
Failed to delete backup with name or ID 'backup-1': Invalid backup:<br>
Incremental backups exist for this backup. (HTTP 400)<br>
```<br>
<br>
We can't delete backup-1 because Cinder considers it a "base" backup<br>
which `has_dependent_backups`. What about backup-2? Same story. Adding<br>
the `--force` flag just gives a slightly different error message. The<br>
*only* backup that Cinder will delete is backup-7 -- the very latest<br>
one. This means that if we want to remove the oldest backups of a<br>
volume, *we must first remove all newer backups of the same volume*,<br>
i.e. delete literally all of our backups.<br>
<br>
Also, we cannot force creation of another *full* (non-incrmental)<br>
backup in order to free all of the earlier backups for removal.<br>
(Omitting the `--incremental` flag has no effect; you still get an<br>
incremental backup.)<br>
<br>
Can we hope for better? Let's reach behind Cinder to the Ceph backend.<br>
Volume backups are represented as a "base" RBD image with a snapshot<br>
for each incremental backup:<br>
<br>
```<br>
# rbd snap ls volume-e742c4e2-e331-4297-<wbr>a7df-c25e729fdd83.backup.base<br>
SNAPID NAME<br>
   SIZE TIMESTAMP<br>
   577 backup.e3c1bcff-c1a4-450f-<wbr>a2a5-a5061c8e3733.snap.<wbr>1535046973.43<br>
10240 MB Thu Aug 23 10:57:48 2018<br>
   578 backup.93fbd83b-f34d-45bc-<wbr>a378-18268c8c0a25.snap.<wbr>1535047520.44<br>
10240 MB Thu Aug 23 11:05:43 2018<br>
   579 backup.b6bed35a-45e7-4df1-<wbr>bc09-257aa01efe9b.snap.<wbr>1535047564.46<br>
10240 MB Thu Aug 23 11:06:47 2018<br>
   580 backup.10128aba-0e18-40f1-<wbr>acfb-11d7bb6cb487.snap.<wbr>1535048513.71<br>
10240 MB Thu Aug 23 11:22:23 2018<br>
   581 backup.8cd035b9-63bf-4920-<wbr>a8ec-c07ba370fb94.snap.<wbr>1535048538.72<br>
10240 MB Thu Aug 23 11:22:47 2018<br>
   582 backup.cb7b6920-a79e-408e-<wbr>b84f-5269d80235b2.snap.<wbr>1535048559.82<br>
10240 MB Thu Aug 23 11:23:04 2018<br>
   583 backup.a7871768-1863-435f-<wbr>be9d-b50af47c905a.snap.<wbr>1535048588.26<br>
10240 MB Thu Aug 23 11:23:31 2018<br>
   584 backup.b18522e4-d237-4ee5-<wbr>8786-78eac3d590de.snap.<wbr>1535052729.52<br>
10240 MB Thu Aug 23 12:32:43 2018<br>
```<br>
<br>
It seems that each snapshot stands alone and doesn't depend on others.<br>
Ceph lets me delete the older snapshots.<br>
<br>
```<br>
# rbd snap rm volume-e742c4e2-e331-4297-<wbr>a7df-c25e729fdd83.backup.base@<wbr>backup.e3c1bcff-c1a4-450f-<wbr>a2a5-a5061c8e3733.snap.<wbr>1535046973.43<br>
Removing snap: 100% complete...done.<br>
# rbd snap rm volume-e742c4e2-e331-4297-<wbr>a7df-c25e729fdd83.backup.base@<wbr>backup.10128aba-0e18-40f1-<wbr>acfb-11d7bb6cb487.snap.<wbr>1535048513.71<br>
Removing snap: 100% complete...done.<br>
```<br>
<br>
Now that we nuked backup-1 and backup-4, can we still restore from<br>
backup-7 and launch an instance with it?<br>
<br>
```<br>
openstack volume create --size 10 --bootable volume-foo-restored<br>
openstack volume backup restore backup-7 volume-foo-restored<br>
openstack server create --volume volume-foo-restored --flavor medium1<br>
instance-restored-from-backup-<wbr>7<br>
```<br>
<br>
Yes! We can SSH to the instance and it appears intact.<br>
<br>
Perhaps each snapshot in Ceph stores a complete diff from the base RBD<br>
image (rather than each successive snapshot depending on the last). If<br>
this is true, then Cinder is unnecessarily protective of older<br>
backups. Cinder represents these as "with dependents" and doesn't let<br>
us touch them, even though Ceph will let us delete older RBD<br>
snapshots, apparently without disrupting newer snapshots of the same<br>
volume. If we could remove this limitation, Cinder backups would be<br>
significantly more useful for us. We mostly host servers with<br>
non-cloud-native workloads (IaaS for research scientists). For these,<br>
full-disk backups at the infrastructure level are an important<br>
supplement to file-level or application-level backups.<br>
<br>
It would be great if someone else could confirm or disprove what I'm<br>
seeing here. I'd also love to hear from anyone else using Cinder<br>
backups this way.<br>
<br>
Regards,<br>
<br>
Chris Martin at CyVerse<br>
<br>
______________________________<wbr>_________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack</a><br>
</blockquote></div><br></div>