| commit | 79a22dff60a53c0e8c8d0812ceb3d739728cacba | [log] [tgz] |
|---|---|---|
| author | guilhermesteinmuller <gsteinmuller@vexxhost.com> | Tue Mar 30 21:23:34 2021 -0300 |
| committer | guilhermesteinmuller <gsteinmuller@vexxhost.com> | Tue Mar 30 21:23:34 2021 -0300 |
| tree | 4376fb4094e1f92845ee434618effa021f7c3c1f | |
| parent | 8c1e0dc633f070ed93e3f517d65e7d28556427d3 [diff] |
update requirements
This solution is a volume-level scheduled backup to implement a non-intrusive automatic backup for Openstack VMs.
All volumes attached to the specified VMs are backed up periodically.
File-level backup will not be provided. The volume can be restored and attached to the target VM to restore any needed files. Users can restore through Horizon or the cli in self-service.
The solution backs up all volumes attached to VMs which have a pre-defined metadata set, for example, backup=yes. First, it gets the list of VMs which have backup metadata and the list of volumes attached to the VMs in the given project by consuming the Openstack API (nova-api and cinder-api). Once the volume list is prepared, then it consumes cinder-backup API to perform the backup. Once the backup is successful, the backup time is updated in the metadata - last-backup-time of the VM.
skip-volume-backup flag.Based on the configured retention policy, the volumes are removed. Openstack API access policies are customized to make only the retention service be able to delete the backups and users not.
Cinder backup service is running on the dedicated backup host and it can be scaled across multiple backup hosts.
Once the backup is finished, the results are notified to the specified users by email regardless of whether it was successful or not (the email will be one digest of all backups). Backup result HTML Template
Users can configure the settings to control the backup process. The parameters are;
This project will need a basic HTTP API. The primary reason for this is because when a user will attempt to delete a backup, we will use oslo.policy via HTTP to make sure that the backup they are attempting to delete is not an automated backup.
This API will be unauthenticated and stateless, due to the fact that it is simply going to return the plain-text string True or fail with 401 Unauthorized. Because of the simplicity of this API, Flask is an excellent tool to be able to build it out.
The flow of the HTTP call will look like the following:
__automated_backup=True then deny, otherwise allow.With that flow, we’ll be able to protect automated backups from being deleted automatically. In order to build a proper architecture, this application will be delivered as a WSGI application so it can be hosted via something like uWSGI later.
The conductor will be an independent daemon that will essentially scan all the virtual machines (grouped by project) which are marked to have automatic backups and then automatically start queueing up backups for them to be executed by Cinder.
Once backups for a project are done, it should be able to start running the rotation policy that is configured on all the existing volumes and then send out a notification email afterwards to the user.
The daemon should be stateful and ensure that it has its own state which is stored inside of a database.