OSS bucket lifecycle policy fails to archive inactive invoice PDFs

Cloud Platforms Alibaba Cloud
, , , , , , , ,
1

Our OSS lifecycle policy is not moving inactive invoice PDFs to Archive storage after 90 days as configured. We store customer invoices in an OSS bucket with a lifecycle rule that should transition objects to Archive storage when they haven’t been modified for 90 days, but files from August (120+ days old) are still in Standard storage.

Current lifecycle policy configuration:

<Rule>
  <ID>archive-old-invoices</ID>
  <Prefix>invoices/</Prefix>
  <Status>Enabled</Status>
  <Transition>
    <Days>90</Days>
    <StorageClass>Archive</StorageClass>
  </Transition>
</Rule>

I’ve verified the policy is enabled and applies to the correct prefix. However, checking object storage classes shows all files remain in Standard storage regardless of age. This is significantly increasing our storage costs - we’re paying Standard rates for 8TB of old invoices that should be archived.

I’m unsure if the issue is with lifecycle policy syntax, archive storage configuration, or how OSS tracks file modification timestamps. Any insights would be helpful.

2

Another thing to check - Archive storage class has specific requirements. Objects must be at least 60 days old in Standard storage before transitioning to Archive. If you’re moving objects that are exactly 90 days old, but they were created in Standard storage less than 60 days before that, the transition might fail silently.

Also, make sure your bucket has Archive storage class enabled. Some older buckets created before Archive was available need explicit enablement.

3

Yes, backup operations that use CopyObject API will update last-modified time by default. You need to ensure your backup tool uses metadata preservation options. But more importantly, you should separate active and archive buckets rather than relying solely on lifecycle policies if you have processes that touch files regularly.

Also verify that your lifecycle rule is actually running. Check OSS bucket properties > Lifecycle Rules to see the last execution time. Rules run daily but execution isn’t guaranteed immediately at midnight.

4

That’s a good point. I checked several August invoices and their last-modified timestamps show recent dates in November, not August. Our backup process might be copying files and resetting timestamps. Is there a way to preserve original timestamps during copies?

5

Your lifecycle policy syntax looks correct at first glance. However, OSS lifecycle rules are based on object last-modified time, not access time. If your application is updating metadata or re-uploading invoices, that resets the modification timestamp and the 90-day counter starts over.

Check if any processes are touching these files - even metadata updates count as modifications. Use OSS console to view the last-modified timestamp for a few August invoices to confirm they’re actually 120+ days old.

6

Here’s a comprehensive solution addressing all three areas:

Lifecycle Policy Syntax: Your XML policy structure is correct, but let’s add some refinements to ensure proper execution:

<LifecycleConfiguration>
  <Rule>
    <ID>archive-old-invoices</ID>
    <Prefix>invoices/2024/</Prefix>
    <Status>Enabled</Status>
    <Transition>
      <Days>90</Days>
      <StorageClass>Archive</StorageClass>
    </Transition>
  </Rule>
</LifecycleConfiguration>

Key considerations:

  • Wrap rules in <LifecycleConfiguration> root element
  • Use year-based prefixes (invoices/2024/) for better control and testing
  • Days count starts from object creation/last-modified date at 00:00 UTC
  • Lifecycle rules execute once daily, typically between 00:00-08:00 UTC

To verify rule execution, check OSS console > Bucket > Lifecycle > Rule History. If no execution history appears, the rule may not be properly attached to the bucket.

Archive Storage Configuration: Several Archive-specific requirements must be met:

  1. Bucket Compatibility: Verify Archive storage class is enabled:

    • OSS Console > Bucket > Properties > Storage Class Support
    • Should show: Standard, IA, Archive, Cold Archive
    • If Archive is missing, contact Alibaba Cloud support to enable it for your bucket

  2. Minimum Object Size: Archive storage requires objects ≥ 64KB. Smaller files won’t transition and remain in Standard storage silently. Check if any invoice PDFs are below this threshold.

  3. Transition Timing: OSS processes lifecycle rules asynchronously. After an object qualifies (90+ days old), transition may take 24-48 hours. Don’t expect immediate transitions.

  4. Cost Optimization: Archive storage has minimum storage duration (60 days). If you delete archived objects within 60 days, you’re charged for the full 60 days anyway. Plan retention accordingly.

File Modification Timestamps: This is your primary issue. Backup processes are resetting last-modified timestamps, preventing lifecycle transitions:

  1. Identify Timestamp Resets: Use OSS CLI to audit timestamps:

    
ossutil ls oss://bucket/invoices/ --all-versions -d

    Compare creation date vs. last-modified date. If last-modified is recent but creation is old, something is touching the files.

  2. Fix Backup Process: If using OSS CopyObject for backups:

    • Add x-oss-metadata-directive: COPY header to preserve metadata
    • Use server-side copy to avoid re-uploading
    • Better approach: Use OSS versioning instead of backup copies

  3. Alternative Solution - Object Tagging: Instead of relying on last-modified time, use object tags with lifecycle rules:

    <Rule>
  <ID>archive-tagged-invoices</ID>
  <Prefix>invoices/</Prefix>
  <Status>Enabled</Status>
  <Tag>
    <Key>archive-eligible</Key>
    <Value>true</Value>
  </Tag>
  <Transition>
    <Days>1</Days>
    <StorageClass>Archive</StorageClass>
  </Transition>
</Rule>



   Then tag objects programmatically 90 days after creation, regardless of modification time. This decouples archival from file operations.

4. **Immediate Fix:**
   Stop all backup processes that touch invoice files. Manually set object metadata to restore original timestamps using:

ossutil set-meta oss://bucket/invoices/2024-08-file.pdf
x-oss-meta-original-date:2024-08-15
–update


This won't change last-modified for lifecycle purposes, but documents original date.

**Recommended Architecture:**
- Separate buckets: invoices-active (Standard) and invoices-archive (Archive)
- Move files between buckets after 90 days using scheduled task
- This avoids lifecycle policy dependencies on timestamps
- Provides clearer cost visibility and access patterns

**Validation Steps:**
1. Disable backup processes temporarily
2. Create test invoice object with past timestamp
3. Wait 24-48 hours and verify transition to Archive
4. If successful, implement tag-based lifecycle or separate bucket approach
5. Re-enable backups with metadata preservation

The core issue is your backup process continuously resetting last-modified timestamps, making all files appear "new" to the lifecycle policy. Fix the backup metadata handling or switch to a tag-based lifecycle approach to regain control over archival transitions and reduce storage costs.
7

I didn’t know about the 60-day minimum requirement. Our invoices are definitely older than that, but I’ll verify Archive storage is enabled on the bucket. The backup process resetting timestamps is definitely an issue we need to address.