[League\Flysystem\FileExistsException] File already exists at path

[Stuart Cusack]

Ever since the 31st January 2017 my Amazon S3 backups have stopped working with this error:

 [League\Flysystem\FileExistsException]
  File already exists at path

Any ideas? I'm pretty sure the backup manager used to just overwrite existing files. I may have also switched to a laravel forge server at this time so that could have something to do with it.

[Shawn McCool]

Is it possible that the file locally couldn't be cleaned up and it's still there? Is it trying to replace a file with the same name remotely? Have you considered adding a timestamp to the filename?

[Stuart Cusack]

Yes, it is trying to replace an existing file with the same name remotely on S3. My system keeps daily backups but overwrites each day on a monthly cycle. I was sure that this used to work without error, but maybe not.

I guess I'll have to figure out how to alter my scheduled backup command so that it deletes the existing file first. I just thought that overwriting would have been handled by the backup-manager db:backup command...? Is there a parameter for that?

[Shawn McCool]

I believe that Flysystem has a command that overwrites. If you copy a task and replace it with that command then it should work.

I like when mine doesn't overwrite anything, personally. I have thousands of backups on many of my apps. But, the size isn't so big that it's a problem. I've definitely worked on apps whose databases were just too large for this to be a reasonable solution.

I'd love to see a 'procedure' that someone creates that does rolling backups.. Like.. One for every day of the last week.. One for every 3 hours of the last day.. One for every week after the last.

[Stuart Cusack]

I ended up using Laravel's scheduler and the Laravel Filesystem to Storage::delete() the s3 file before running the backup-manager artisan command to make a new backup of the same filename.

My strategy is simple and I wanted to keep S3 storage to a minimum:

//app/Console/Kernel.php

//**add this to imports
use Storage;

protected function schedule(Schedule $schedule)
{

//prepare numeric date parts (leading zeros included)
$year = date("Y");
$day = date("d");
$month = date("m");

//Run daily deletion: connect to S3 and delete any existing daily backup for this day
$schedule->call(function () use ($day) {
    //prepare the file name for todays nightly backup (notice how we need to root folder name in filesystems but not in backup-manager)
    $previous_backup_path = "/mysql-backup/daily/" . $day . ".gz";
    //Use laravels in-built filesystems (needs to be setup in config/filesystems.php)
    Storage::disk('mysql-backup')->delete($previous_backup_path);
})->daily();

//run daily artisan backup (backup-manager package) - occurs at midnight
$schedule->command(
      "db:backup --database=mysql --destination=s3 --destinationPath=/daily/{$day} --compression=gzip"
 )->daily();

//run monthly artisan backup (backup-manager package)
$schedule->command(
      "db:backup --database=mysql --destination=s3 --destinationPath=/monthly/{$year}/{$month} --compression=gzip"
)->monthly();

}

This means I'll always have a history of 31 nightly backups and a full history of monthly backups since the applications launch. This code is still being tested so I'm not 100% sure it works yet.