Laravel-backup: Confused about destination.path

[spencerpieters]

In the past I've successfully used v2.9 of this package. Very happy with it.

I made backups of solutions to subfolders in my S3 bucket, like

/bucket/backups/customer1
/bucket/backups/customer2
etc

These were defined in laravel-backup.php by destination.filesystem ('S3') and destination.path ('backups/customer1' for example)

I've just installed the latest version of this package to use in a new app and I'm confused. It seems that destination.filesystem was replaced by destination.disks, which is fine. But I can no longer get destination.path to work.

I've also played with the backup.name value but I'm unsure what it does.

Anyway, I would like to know how I have to configure laravel-backup.php in version 3.5 of this package. I have an existing backup folder for this project on S3 ... how do I fill in the values for backup.name and destination.path so that the package will store the zips in this existing S3 folder?

[freekmurze]

Hi, in v3 the destination.path configuration option was dropped. I thought a path option was available on the S3- flysystem driver but it turns out it only exists on local.

I'll add path back in the near future. If you need this quick, submit a PR.

[warkior]

Does this mean that I cannot currently have the backup go into a sub-folder on the S3 account? I've been trying to do that, so far with no success. I had set my filesystem S3 bucket to be bucket/path but I'm getting an error.

[ArnaudFeelAndClic]

Hello freekmurze,

Have you create destination.path ?

I try to save my db on a folder that I could choose. Currently, the backup is performed on directory : myProject/ storage/app/http --- myHostName.dev, and i would change this, if it is possible ?

[devinfd]

@freekmurze Same question as @ArnaudFeelAndClic. Have you create destination.path ? I cant update until that exists.

[freekmurze]

So destination.path does not exist anymore in v3. You can use the name key in the config file to determine if which subdirectory of your disk the backup will be stored on S3.

You could try to misuse that setting to also create subdirectories on S3, but I'm thinking that might fail. Test it out!

[itzikbenh]

Any reason you removed it? It's quite essential. No one wants to have a huge list in one folder. Makes more sense to store it in a year/month folder name.
This is a great package and thank you for creating it, but now I can't use it for UX reasons.
Of course configuring the name key won't help.
Make laravel-backup great again!!! :)

[dellow]

Is this likely to be reinstated anytime soon? The name key suggestion doesn't work.
Would find setting an actual path for backups pretty useful.

Thanks.

[snapey]

I prefer to allocate each project a different IAM account and a policy that restricts them to a specific bucket. This is so that if one server is compromised, the attacker cannot find secrets in backup files of other servers and/or delete other backups.
The problem with this approach was that the number of buckets was expanding.
I decided through policy to constrain the user to a 'folder' within a bucket. Adding the folder name to the bucket name caused flysystem driver to supply invalid credentials to S3.

The solution was to
a) decouple the backup name from the APP_NAME
b) create an S3 policy for the sub folder.

For a) I created a .env parameter of BACKUP_NAME and gave it the folder name. My folder was 'sidekick' so BACKUP_NAME = sidekick

Then in config/backup.php change backup name and monitor_backups name to reference the new parameter.

S3 policy is;
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::novate-backups"
]
},
{
"Effect": "Allow",
"Action": [
"s3:"
],
"Resource": [
"arn:aws:s3:::novate-backups/sidekick/",
"arn:aws:s3:::novate-backups/sidekick"
]
}
]
}