You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Lianping Chen (JIRA)" <ji...@apache.org> on 2013/04/26 19:48:16 UTC

[jira] [Updated] (CLOUDSTACK-2216) 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.

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lianping Chen updated CLOUDSTACK-2216:
--------------------------------------

    Description: 
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.


  was:
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}}] }

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.


    
> 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