search

BCDevOps / backup-container

A simple container for a simple backup strategy.
Apache License 2.0
42 stars 56 forks source link

Add mssql plugin. #50

Closed devinleighsmith closed 4 years ago

devinleighsmith commented 4 years ago

Initial attempt. Have tested 1) backup(cron and manual) 2) backup verification 3) restore 4) start/stop 5) db size 6) cleanup 7) ping

devinleighsmith commented 4 years ago

@esune So the one thing that this plugin requires that neither mongo nor postgres need is that the database container needs to have direct access to the backup volume. this is because MSSQL does not support writing files directly to the local container, it only backs files up to the database container. It also doesn't support any parameters to dump the backup to stdout.

Recommended way to backup MSSQL in a non-cloud environment from the command line is to set up a shared drive and then use SQLCMD to backup to the shared drive, which is more or less equivalent to what I've done.

As a result, the database container needs to be able to write the backups to the shared volume directly. I don't see any major drawbacks to this at the time. However, it would be possible to change the backup to a 2 step process: 1) perform the backup 2) use scp or similar to copy the backup file. This does add some undesirable complexity, which is why I went with this approach for now.

esune commented 4 years ago

@devinleighsmith ok, thank you for the clarification. I initially thought that the main database volume would need to be shared, but it sounds like it is just the volume used by the backup container that needs to be shared. If this is the case, should this be changed to SharedAccess so that more than one container can mount it at the same time?

devinleighsmith commented 4 years ago

I've made these changes, going to test everything out in my environment then I'll update this PR.

devinleighsmith commented 4 years ago

@esune Getting this when I tried to switch to SharedAccess: Error from server (Invalid): PersistentVolumeClaim "bk-jcxjin-dev-r9c53stkggh6" is invalid: spec.accessModes: Unsupported value: "SharedAccess": supported values: "ReadOnlyMany", "ReadWriteMany", "ReadWriteOnce"

ReadWriteMany is defined as: ReadWriteMany – the volume can be mounted as read-write by many nodes.

devinleighsmith commented 4 years ago

From the sounds of it I should be good as-is?

WadeBarnes commented 4 years ago

The Backup Volume PVC portion of the template only comes into play when you are using something other than the recommended nfs-backup class. nfs-backup storage cannot be provisioned via template, and is typically provisioned through the catalog. It is automatically provisioned as RWX (Read-Write-Many) (aka Shared). If you are using netapp-file-standard storage for the Backup Volume (because you're instance is not in prod for instance), you could provision the volume as RWX (Read-Write-Many), rather than RWO (Read-Write-Once) to make it clear it's being shared.

WadeBarnes commented 4 years ago

@devinleighsmith, regarding docker/uid_entrypoint, does the underlying base container not run in OpenShift natively?

devinleighsmith commented 4 years ago

There is a known issue with the mssql docker image. The openshift assigned random uuid isn't able to run sqlcmd commands. uid_entrypoint works around that issue.

So to answer your question directly, the container will run, but won't be able to run sqlcmd commands (which is obviously required by our workflow).

asanchezr commented 4 years ago

Looks good. I have no further comments other than what Jeremy already pointed out about the git repo in config should point to BCDevOps not your fork

LOL - disregard this comment! I was reviewing a related PR on our repo and posted the review here