DarkJoney
New Member
Dear Colleagues,
I would like to share with you a current situation I am analysing, since I am seeking some useful ideas on the matter. Although I am coming from an enterprise hybrid-cloud operations background, I am lacking some Progress-specific skills since I have just recently joined a big SaaS that has Progress 12 under the hood.
I was tasked to analyze the backup process at our setup, and the input data is that we are having over 4PB of backups, which mainly consist of the Progress databases of our customers we are hosting. We are hosted at the datacenter, Progress is running on the Windows Server hosts running over EXSi, EXSi is backed up with Snapshots + Commvault agent that backs up to the backup area (HDDs + tape). Backup has a retention period of 60 days, and we perform it in a 1-week cycle, where every Sunday, incremental backups are compiled into a full backup. So, every backup point is stored for 62-63 days. The datacenter is performing deduplication (which seems pointless in the case of Progress databases), and I have requested information on whether they apply Commvault compression.
There are a lot of BIG Progress DB servers, we have over 10 TBs at the shared ones. We perform online backups using Probackup on the same hosts with a 3-day cycle, which are later compressed with 7Zip (it yields excellent results!). However, Commvault backups only a volume containing the actual running Progress Databases themselves. So, we have 3 hot and 1 "cold" copy with retention of 60 days. The system is inherited from the reusable VMWare template; we are fine with it. I was thinking about what we can exclude at the target backup drive with Progress DBs, but utility data usually takes just a few gigabytes and there is no really else to exclude.
The main problems in the story we can't step aside for 60-day retention (certification) and THE BILL for the backup. So, I would like to ask your opinion about:
- What can we still really optimize in the current setup? Can we still exclude something from the Progress DB instances? I wonder how we can apply any efficient compression while still maintaining the ability of the swift database rollback in case of something.
- Is there anything on the Progress side we are not using, but should consider using? I wonder if we can optimize storaging and automatically bring more efficient backup using what DC is offering to us. We don't use after imaging for now.
- What are the best practices in the Progress DB backup in general? Progress docs mention so-called "backup strategies", but I am not sure from what are they concluded.
- or should we consider any other backup strategy? (using proquiet, e.t.c, backup windows, and other storage approaches while maintaining, or using offline backup, do a compression, and use the backup drive as a target for Commvault, e.t.c)
So, I would greatly welcome any guidance/tipp on this matter, because the most obvious non-Progress related options we have already implemented.
Beers or good whiskey from the saved money from us
Thank you very much!
Best regards,
Dmytro
I would like to share with you a current situation I am analysing, since I am seeking some useful ideas on the matter. Although I am coming from an enterprise hybrid-cloud operations background, I am lacking some Progress-specific skills since I have just recently joined a big SaaS that has Progress 12 under the hood.
I was tasked to analyze the backup process at our setup, and the input data is that we are having over 4PB of backups, which mainly consist of the Progress databases of our customers we are hosting. We are hosted at the datacenter, Progress is running on the Windows Server hosts running over EXSi, EXSi is backed up with Snapshots + Commvault agent that backs up to the backup area (HDDs + tape). Backup has a retention period of 60 days, and we perform it in a 1-week cycle, where every Sunday, incremental backups are compiled into a full backup. So, every backup point is stored for 62-63 days. The datacenter is performing deduplication (which seems pointless in the case of Progress databases), and I have requested information on whether they apply Commvault compression.
There are a lot of BIG Progress DB servers, we have over 10 TBs at the shared ones. We perform online backups using Probackup on the same hosts with a 3-day cycle, which are later compressed with 7Zip (it yields excellent results!). However, Commvault backups only a volume containing the actual running Progress Databases themselves. So, we have 3 hot and 1 "cold" copy with retention of 60 days. The system is inherited from the reusable VMWare template; we are fine with it. I was thinking about what we can exclude at the target backup drive with Progress DBs, but utility data usually takes just a few gigabytes and there is no really else to exclude.
The main problems in the story we can't step aside for 60-day retention (certification) and THE BILL for the backup. So, I would like to ask your opinion about:
- What can we still really optimize in the current setup? Can we still exclude something from the Progress DB instances? I wonder how we can apply any efficient compression while still maintaining the ability of the swift database rollback in case of something.
- Is there anything on the Progress side we are not using, but should consider using? I wonder if we can optimize storaging and automatically bring more efficient backup using what DC is offering to us. We don't use after imaging for now.
- What are the best practices in the Progress DB backup in general? Progress docs mention so-called "backup strategies", but I am not sure from what are they concluded.
- or should we consider any other backup strategy? (using proquiet, e.t.c, backup windows, and other storage approaches while maintaining, or using offline backup, do a compression, and use the backup drive as a target for Commvault, e.t.c)
So, I would greatly welcome any guidance/tipp on this matter, because the most obvious non-Progress related options we have already implemented.
Beers or good whiskey from the saved money from us

Thank you very much!
Best regards,
Dmytro