Description of problem: Using cinder backup with NFS backend, everything works fine, except that when we delete a backup the actual "content" of the backup gets deleted but not the directory structure on the NFS share. (overcloud) [stack@undercloud-0 ~]$ openstack volume backup list --long --all-projects -c Container -c ID +--------------------------------------+--------------------------------------------+ | ID | Container | +--------------------------------------+--------------------------------------------+ | 17aed1d1-33ba-466e-a51f-d6af156d120e | 17/ae/17aed1d1-33ba-466e-a51f-d6af156d120e | +--------------------------------------+--------------------------------------------+ [backups]# ll total 0 drwxr-xr-x. 3 root root 16 Feb 2 06:28 02 drwxr-xr-x. 3 root root 16 Feb 2 06:33 17 drwxr-xr-x. 3 root root 16 Feb 2 06:19 5a drwxr-xr-x. 3 root root 16 Feb 2 06:20 e4 drwxr-xr-x. 3 root root 16 Feb 2 06:32 e6 The only available volume backup is 17aed1d1-33ba-466e-a51f-d6af156d120e and the rest of the backups were deleted yet their corresponding directories are still present in the backend. There is no content in the deleted volume backup directories. Version-Release number of selected component (if applicable): RHOSP13 How reproducible: Steps to Reproduce: 1. Deploy RHOSP13 with cinder backend as NFS and configure cinder-backup service. 2. 3. Actual results: Directories for deleted volume backup are not deleted. Expected results: Directories for deleted volume backup should also be deleted. Additional info:
Greetings Rohini Diwakar, This is the expected behaviour. This happens because the backup service might reuse some sub-folders. Backup data and metadata will be written to the repository at unique paths that are a function of the backup ID. That path will be stored in the backup record service_metatdata so that it can be used to navigate to the backup data and metadata for restore and delete operations (thanks Tzach for the detailed explanation).
Just another point in order to assess this fix: apart from the wasted inodes, does having the leftover empty directories around lead to any other issue?
Luigi, Even if not on this specific case, left unchecked these empty folders may potentially cause problems, depending on NFS server/storage system's limits, it could affect other deployments/releases too. Reaching limits may cause: slow to no access, failure to backup/restore just when you need it most. Agreed low priority for sure, as we need a whole lot of empty folders before things may fail. And yep 13 EOL-ing soon means it might not be a good place to start fixing this.