[
https://issues.apache.org/jira/browse/CLOUDSTACK-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655893#comment-13655893
]
Lianping Chen commented on CLOUDSTACK-2216:
-------------------------------------------
I have fixed this issue in our deployment. I shared the fix by sending in a
pull request for the code changes I made.
https://github.com/apache/incubator-cloudstack/pull/2.
> CloudStack Manager sends wrong validBackupUUIDs to Secondary Storage VM when
> clean up snapshot backup. This causes the snapshots backup not garbage
> collected correctly and gets the secondary storage filled up.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-2216
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2216
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.0.0
> Environment: CloudStack Manager running on CentOS
> Secondary Storage Manager running on CentOS
> Hosts running on CentOS
> KVM
> Reporter: Lianping Chen
> Labels: backup, cleanup, snapshots
>
> We are running CloudStack version 4.0.0.20121024012150. We defined a
> recurring snapshots backup policy: take a snapshot daily at 23:00 and only
> keep the 2 most recent backups.
> According to this policy, the validBackupUUIDs of
> CleanupSnapshotBackupCommand should only contain the 2 most recent backups.
> But what the CloudStack Manager actually sends out to Secondary Storage VM
> contains more than 2 items in validBackupUUIDs, as shown in the log below.
> 2013-04-26 00:02:56,029 DEBUG [agent.transport.Request]
> (StorageManager-Scavenger-1:null) Seq 25-300836003: Sending { Cmd , MgmtId:
> 153252621541, via: 25, Ver: v1, Flags: 100011,
> [{"CleanupSnapshotBackupCommand":{"secondaryStoragePoolURL":"nfs://172.18.30.12/export/secondary","dcId":1,"accountId":2,"volumeId":2422,"validBackupUUIDs":["/snapshots/1/2/2422/gitfraud01_DATA-2396_20130311171422","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130322114746","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130414110421","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130415110421","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130416110053","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130417110053","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130418110053","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130419110053","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130420110053","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130421110053","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130422110053","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130424110406","/snapshots/1/2/2422/gitfraud01_DATA-2396_20130425110406"],"wait":0}}]
> }
> We observed this problem for many of the VMs we set up the recurring backups.
> The consequence of this is that the snapshots backups that are supposed to be
> cleaned up remain in the file system and potentially fill up the secondary
> storage.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
