Engage with the community by providing your idea to solve the selected project. You can write it as a reply to this topic or start a new one in the respective project’s forum.
APPLICATION TEMPLATE FOR STUDENTS
When submitting a proposal, make sure to include these key elements:
About You: Share your background, experience, education, and hobbies! Let us get to know you.
Project Background: What’s the current state of things, and what problems need solving?
Project Design & Description: A creative and detailed plan of what you’ll be working on.
Benefits to Users and Developers: How will your contribution make a difference?
Deliverables: What awesome things will you deliver by the end of the project?
Scheduling: A roadmap to success—timeline for your work and key milestones.
Other Commitments: Let us know about exams, part-time work, holidays, or anything else!
Community Engagement: Have you contributed before? Share your PRs, forum discussions, and other open-source activities!
We’re very happy that you’re interested in contributing to our projects. Let me quickly answer your questions:
There’s no ceph support yet in Percona Backup for MongoDB. Only min.io is supported. Users that would like to use Ceph storage experience issues and it requires a lot of manual work to set it up as S3-compatible.
No, there’s no. However, you may check how min.io SDK is leveraged in the PBM project.
Here’s a simple one if you would like to start: Jira
There are some challenges. For example:
PBM is traditionally a “logical/physical” backup tool that talks to mongod. To use RBD, you’d need to coordinate the MongoDB “fsync and lock” state with the RBD snapshot command to ensure a crash-consistent state.
Using librados library
Exploring Cloud Transition (Bucket Lifecycle)
Exploring RGW that supports S3 Object Lock - for backup retention protection.
However, note that Percona has not yet been accepted as an organization for Google Summer of Code. We should know it by February 18, 2026 7:00 PM UTC.
Regarding GSoC acceptance - understood! I’m committed to contributing regardless of the outcome. Even if Percona isn’t selected for GSoC 2026, I’m interested in this work and would like to continue learning.
I’ll keep you posted on my progress with the Jira issue.
I’ve completed the warm-up task (PBM-843) and opened a PR:
The change improves error handling for the inMemory storage engine by returning a clear message instead of the raw $backupCursor error. All existing tests pass locally using Docker.
Please let me know if any adjustments or additional tests are needed.
Thanks @Anuja_Kuchipudi ! We’ll review this shortly. I’m not sure if that’s the best way to check the storage engine. Maybe executing db.serverStatus().storageEngine would be cleaner. Anyway, let’s continue the discussion in the PR thread. Thank you again for the contribution!
Thank you for the review, Radoslaw! That makes sense—checking the storage engine via serverStatus() is much more robust than string matching the error. I will look into how to execute that command using the existing mongo-driver connection in physical.go and update my PR shortly. I’ll ping you once the new commit is pushed
Sadly, Google was unable to accept Percona this year as a mentoring organization for Google Summer of Code 2026. This year they received an more applications, many more than available slots.
Still, we welcome all of you in our community and invite you to collaborate on Percona projects. If you’re interested, let us know, and we will support you in collaboration, provide the required help to onboard the project, and provide some mentoring.
We hope for another year when Percona will accepted!
Hi Radoslaw, thank you for letting me know. I’m disappointed about GSoC, but I’ve learned so much just from this warm-up task! I still want to finish the fix for PBM-843 using your serverStatus() suggestion—it’s great practice for me. I’d love to stay connected for future community projects