We have configured our cloudberry so that "Keep number of versions (for each file)" is 3. Our S3 bucket is versioned, so technically we have a full history on the S3 side rather than just three days. Anything older than 3 days is showing as deleted in S3, but we can manually recover these deleted objects from the AWS console.
We now want to restore a version of a file from 2 years ago. How can we do this with the cloudberry software? We tried specifying a date range for the restore, but this didn't work. We tried undeleting the object in S3, but the cloudberry software did not show this as a version that was eligible for restoration.
Is there any way to get this object restored?
Thanks,
Brian
PS We are using CloudBerry Backup Ultimate Edition 6.2.3.15
I'm not exactly clear why you're using versioning on the S3 side. All versioning should be handled by our software. We do not support S3 versioning directly, but having it on should not pose any issues. If you could elaborate a bit more here I'd be interested to understand more about why you're using it. Are you using object lock, perhaps?
When you restore with our software, it uses the local repository database that is built when backups and purge operations occur so it knows what files are in cloud storage. It does not do a real-time scan as that would be hugely time-consuming. If the file is up there and properly logged in the repository database, when you restore that file you should see all the versions that you're keeping. Looks like you're keeping three versions at the most, so you would likely not see more than that.
If you're not seeing versions or the file itself, then it's likely it got removed through some other means or because you don't have your retention settings set properly. There is an option in the retention tab to always keep the latest version of every file and also options about how you want to handle files that are deleted locally.
If you restore the file from S3 versioning, and it's really in the correct format that we need, then you can try synchronizing the repository in the software as that will read what's in the bucket and synchronize it with the local database. Then you should see the file when you do the restore.
I'm assuming you're trying the restore from the same computer that did the backup, or at the very least, on a new computer that uses the same backup prefix. If you don't have access to the original computer, and you're doing this from a new computer, then you need to make sure the backup prefix is the same. However, setting the backup prefix would usually cause the repository to synchronize automatically, so I'm guessing that's not the issue. Please refer to this article about how to do a manual synchronize and then report back the results.
> I'm not exactly clear why you're using versioning on the S3 side. All versioning should be handled by our software. We do not support S3 versioning directly, but having it on should not pose any issues.
This was setup by my predecessor, so I'm not sure exactly why it was done this way. I understand now that we should be using a longer retention period in the Cloudberry software instead of depending on versioning in S3.
> If you restore the file from S3 versioning, and it's really in the correct format that we need, then you can try synchronizing the repository in the software as that will read what's in the bucket and synchronize it with the local database. Then you should see the file when you do the restore.
This worked perfectly! We did the following:
- Undeleted the object in S3
- Synchronized the repository from S3
- Performed a restore in the normal fashion