Using BackupManager with an S3 *private* bucket

[emjayess]

Hi. I'm attempting to configure BackupManager to backup an application's database to an AWS S3 private bucket:

• The bucket exists, along with a destination directory for backups within it.
• AWS access keys, etc, are provisioned and configured for access grants to S3
• These settings are setup in the .env file
• config/filesystems.php has an entry named s3_private
• config/backup is configured to utilize s3_private

And from the Backups page in Backpack, I am able to successfully create a backup, and confirm it exists in the desired bucket and directory on S3, directly inspecting from the AWS console...

The Backups page in Backpack also is listing these backup archives that exist.

However, the Backups page offers no link to download the generated backup, and the Delete action fails. Is this because it is a private S3 bucket? The S3 policy for the role with programmatic access keys is the S3 full access policy. I might presume the links for download and delete may need to be generated as signed urls, for a private S3 bucket... is BackupManager built to do this, or not?..

Saving backups to a private disk seems like a common use case, so I am a little surprised this isn't documented. We don't want to end up in the news for sharing our database backups with the world, after all.

[karandatwani92]

Hey @emjayess
Thanks for asking.

Hey @pxpm
We can see here, if the disk is not local, the download URL would be null.
can we cover the S3 bucket or suggest some steps for this?

Thanks

[pxpm]

Hey @emjayess thanks for the heads up.

This package does not support other than local disks at the moment.
Not only where @karandatwani92 mentioned, that is not actually the problem, we should probably keep returning null there because for s3 private buckets you generate a temporary link for the download, and I think it does not make sense to show a table with a link, that only works for say 1 minute.

I think the changes need to happen mainly in: https://github.com/Laravel-Backpack/BackupManager/blob/63e41c770e018e99d3d9f6bf0eae41ae6cc30bf7/src/app/Http/Controllers/BackupController.php#L100

We haven't worked much on this package as most of the hosts today offer some kind of backup on the infra side, and backups on the application area are not used that much anymore.

I would be open to review a PR to add support for S3 buckets in this package, but I am afraid I cannot commit to create that PR myself, sorry.

We support it in our upload fields, it's not something complicated to implement https://github.com/Laravel-Backpack/CRUD/blob/93279f6e2f313697180ef4fd290cc03fd7b056ac/src/resources/views/crud/fields/upload.blade.php#L17

@emjayess you can scratch your own itch by using a custom controller instead of the one we provide here, you can do that by:

1 - creating a file in routes/backpack/backupmanager.php with the following contents:

// notice \App\MyCustomController should be replaced by the actual controller you are going to use
Route::group([
    'prefix'     => config('backpack.base.route_prefix', 'admin'),
    'middleware' => ['web', config('backpack.base.middleware_key', 'admin')],
], function () {
    Route::get('backup', [\App\MyCustomController::class, 'index'])->name('backup.index');
    Route::put('backup/create',  [\App\MyCustomController::class, 'create'])->name('backup.store');
    Route::get('backup/download/',  [\App\MyCustomController::class, 'download'])->name('backup.download');
    Route::delete('backup/delete/',  [\App\MyCustomController::class, 'delete'])->name('backup.destroy');
});

2 - Create the custom controller extending the package one

<?php

namespace App;

class MyCustomController extends \Backpack\BackupManager\app\Http\Controllers\BackupController
{
    // overwrite the needed methods here

    public function index()
    {
        dd('index overwrite');
    }
}

If you endup with a solution we can incorporate in the package and make available for everyone, like I said feel free to submit the PR.

Cheers

[emjayess]

Thanks for the insight, context, and feedback @pxpm ..

Felt to me like this would be common (if it were a widely relied upon feature, at least) use case, so worth posing the inquiry to the more informed members here..

"We haven't worked much on this package as most of the hosts today offer some kind of backup on the infra side, and backups on the application area are not used that much anymore."

Makes sense, also.

I'll consider carving up some time to scratch the itch on this one.