Add Drush command for running a quick backup

Sorry to provide a patch 2 days after I assigned my self.
I was busy those days and forgot about this issue.

Anyway here is patch for it. We should evaluate what will be committed first: this issue or #2968766: Add Drush commands for getting details of available configurations.
One of them will need a re-roll anyway.

Hi!
I tested this patch and I received a error message when I tried to do my backup and not had a Settings Profile configured. After I add a Settings Profile, the drush command works in all backup options.

Drush 10

Hi @Damien! I'm using Drush 10.5.0 version.

Is it okay with Drush 10 version?

If yes, I can fix the problem reported in #5.

Patch #10 looks good to me.
I can make a backup when I had or when I not had a Settings Profile configured.

@paulocs thanks for your time implementing this! I can confirm, patch #10 is looking great!

Just one minor suggestion. Would it be possible to add flags to the command? I am currently working on an automatic setup for a Drupal dev environment, and I would love to use backup_migrate on startup via script!

Maybe something like this:

drush backup_migrate:quick_backup --default_db --destination=private_files

+1 for #12! Good point. I'd even go one step further and would suggest running the backup to default destination with default settings like it was possible in Drupal 7 with one command: drush bb.
There's a connection to this issue: #3124408: [PP-1] Admin Menu Shortcut / Shortcut Block ("One Click Backup") both would benefit from being able to define a default backup destination! :)

I guess a maintainer should decide. What do you think @DamienMcKenna?

My vote would go for committing this to have ANY solution and then create a follow-up for these two additions?

Edit / Update: I created a follow-up feature request to be able to define defaults: #3251217: Allow to define one backup profile, source and target as default for quick backup via UI and Drush so I'd vote for a "drush bb" command like in Drupal 7 doing a quick backup, drush bb -i(=interactive) with the current behaviour and alternatively parameters to override default values. That would be perfect in my eyes. :)

yes i can do what Grevil suggested. Should we do it in this issue or in a followup issue?

Thank you @paulocs,

as written in #13 I'd suggest to create the command here, but perhaps postpone this on #3251217: Allow to define one backup profile, source and target as default for quick backup via UI and Drush first?

... so I'd vote for a "drush bb" command like in Drupal 7 doing a quick backup, drush bb -i(=interactive) with the current behaviour and alternatively parameters to override default values.

To better explain it:

What I'd suggest to make things as simple, understandable and flexible as possible:
- Create a drush bam-backup (shortcutdrush bb) command like it existed in Drupal 7. It should require no parameters and use the defaults for profile, source and target.
- Therefor fix #3251217: Allow to define one backup profile, source and target as default for quick backup via UI and Drush to be able to define defaults
- Allow to override the defaults, if parameter is given.
- Bonus: Add a "-i" (interactive) parameter to let the command which asks for the parameters instead providing the possible options like you did in your patch perfectly!

I guess that would be most future-proof.

Perhaps until the other issue is fixed, we could require the parameters?

Here you can find the D7 implementation we should comply with: https://drushcommands.com/drush-7x/backup-migrate/bam-backup/

This solution is simple to run and also flexible as it offers the option to use it in scripts or manually and Drupal 7 users don't have to use a different command, which worked perfectly.

I created a new patch with the flags suggested in #12.

So now you can run drush bb in an interactive way or not.

@paulocs this works perfectly, thank you for the quick implementation!

Just one more tiny addition, maybe we could add a --replace flag, for cases, where we would like to replace the last backup with a new backup, instead of always adding a backup.

Thank you for the review @Grevil!

Just one more tiny addition, maybe we could add a --replace flag, for cases, where we would like to replace the last backup with a new backup, instead of always adding a backup.

I wouldn't say it doesn't make sense, especially in development environments, but it's very untypical. We should discuss here if it's worth a separate issue, but shouldn't be added here, I think!

I tend to say no from my experience ... but let's hear further voices ;)

Sooo great news, thank you very much @Damien! :) Happy to be able to use this again!!

@DamienMcKenna 5.1.x still seems to be far away? Would it be possible to cherry-pick this into 5.0.x perhaps? Two years later I'm still waiting to be able to use this functionality :(

Hi i do agree with Anybody, should we reopen this issue or create a new one to backport this to 5.0.