Active
Project:
Backup and Migrate
Version:
5.0.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
20 Jul 2018 at 21:55 UTC
Updated:
9 Jul 2021 at 17:48 UTC
Jump to comment: Most recent
Comments
Comment #2
couturier commentedHave you tried just using the "quick backup" option? There have been a few reports lately of people having trouble using the "entire site" option in the special configurations. Just go to the main module page and do a quick backup and let us know how it goes.
Comment #3
crystalgrafix commentedHi,
I can confirm that this issue is still happening. Entire site backup via 'quick backup' excludes 'vendor' and other files like 'composer.json'. Basically it only backs up the content within 'web' folder.
Comment #4
beauregard commentedhi
I have the same problem and I wonder how people are doing backups? Also I searched first long time in forums, because I thought it just cant be and I overlook something.
What is the use of the module if only "/web" folder is backed up? Since drupal should be installed with composer and also configuration files are strongly recommended to be outside of web-folder.
Or is there an option to configure the backup module that it does not only backup the web folder?
Comment #5
damienmckennaI suspect the problem is that B&M only backups the directory the "index.php" file is in, it doesn't look at the parent directory at all.
So if B&M were to backup the parent directory too it'd start being more complicated as lots of web hosting providers will have a ton of other things in that directory, e.g. email, hosting account configuration, etc, etc; it starts getting rather complicated.
Comment #6
beauregard commentedwell, the module should not backup by default the parent directory, but it should have an option to include it. As Drupal Administrator you should anyway look exactly what you are doing with backups and restore, so the option to include the parent directory is an easy one to understand.
But without, it is useless, because the parent directory holds necessary information.
Since this option is not included and drupal 8 is out several years, I wonder: How are others doing scheduled backups?
Comment #7
j-lee@beauregard Our strategy is to backing up the database only. All the vendors stuff etc. is managed via git and composer and could restored with a simple composer install. We have a file based backup at our webserver, so we don't have to use this module for that.
If you don't have an external backup solution, you should backup the files directory. But you are right, what happens with a private file system outside the Drupal root?
Comment #8
beauregard commentedyes, we use also git. and we have an external daily backup solution with the hoster. However, this I prefer to use only in emergencies.
The problem with git is: files/images uploaded by users are not in the repository, or at least not in the moment when uploaded by users.
We are currently testing another external backup system.
Another option could maybe be sponsor this feature? I assume it would be technically not too complex to include such a checkbox "include parent folder" for developers who have developed parts of this module. Would it be an option that such a feature is sponsored?
Comment #9
damienmckennaIf you're already storing the codebase in git, why not just back up the site's private, public files and database and let git do what it does best?
Comment #10
beauregard commentedyes, we were thinking about that. However, I prefer to have one full backup to reduce any risk.
we dropped now the backup module and wrote some bash scripts which backup files & db and save it in a remote cloud encrypted
Comment #11
drupaldope commentedI have the same need.
GIT could indeed store private files as well as composer json and lock, but there is the risk of storing different states and when restoring, there is the risk of restoring the wrong versions.
I do expect from a backup-restore utility that it backups and restores the full functionality of a site from a *snapshot*, including any configuration files, which means the composer files should also be backed up.
Comment #12
damienmckennaMoving 8.x-4.x issues to 5.0.x because the older branch is no longer supported.