freezer.common.client_manager
Modulefreezer.common.config
Modulefreezer.engine.engine
Modulefreezer.engine.manager
Modulefreezer.engine.nova.nova
Modulefreezer.engine.osbrick.brick_utils
Modulefreezer.engine.osbrick.client
Modulefreezer.engine.osbrick.osbrick
Modulefreezer.engine.osbrick.volume_actions
Modulefreezer.engine.rsync.pyrsync
Modulefreezer.engine.rsync.rsync
Modulefreezer.engine.rsyncv2.pyrsync
Modulefreezer.engine.rsyncv2.rsyncv2
Modulefreezer.engine.tar.tar
Modulefreezer.engine.tar.tar_builders
Modulefreezer.exceptions.engine
Modulefreezer.exceptions.utils
Modulefreezer.job
Modulefreezer.lib.pep3143daemon.daemon
Modulefreezer.lib.pep3143daemon.pidfile
Modulefreezer.main
Modulefreezer.mode.cinder
Modulefreezer.mode.cindernative
Modulefreezer.mode.fs
Modulefreezer.mode.mode
Modulefreezer.mode.mongo
Modulefreezer.mode.mysql
Modulefreezer.mode.nova
Modulefreezer.mode.sqlserver
Modulefreezer.openstack.admin
Modulefreezer.openstack.backup
Modulefreezer.openstack.osclients
Modulefreezer.openstack.restore
Modulefreezer.scheduler.arguments
Modulefreezer.scheduler.daemon
Modulefreezer.scheduler.freezer_scheduler
Modulefreezer.scheduler.scheduler_job
Modulefreezer.scheduler.utils
Modulefreezer.snapshot.lvm
Modulefreezer.snapshot.snapshot
Modulefreezer.snapshot.vss
Modulefreezer.storage.base
Modulefreezer.storage.exceptions
Modulefreezer.storage.fslike
Modulefreezer.storage.local
Modulefreezer.storage.multiple
Modulefreezer.storage.physical
Modulefreezer.storage.s3
Modulefreezer.storage.ssh
Modulefreezer.storage.swift
Modulefreezer.tests.commons
Modulefreezer.tests.integration.common
Modulefreezer.tests.integration.test_agent
Modulefreezer.tests.integration.test_rsync_backup
Modulefreezer.tests.integration.test_version
Modulefreezer.tests.unit.engines.nova.test_nova
Modulefreezer.tests.unit.engines.rsync.test_pyrsync
Modulefreezer.tests.unit.engines.tar.test_tar_builders
Modulefreezer.tests.unit.openstack.test_osclients
Modulefreezer.tests.unit.openstack.test_restore
Modulefreezer.tests.unit.scheduler.test_scheduler_daemon
Modulefreezer.tests.unit.scheduler.test_scheduler_job
Modulefreezer.tests.unit.snapshot.test_lvm
Modulefreezer.tests.unit.snapshot.test_vss
Modulefreezer.tests.unit.storages.test_local
Modulefreezer.tests.unit.test_job
Modulefreezer.tests.unit.utils.test_checksum
Modulefreezer.tests.unit.utils.test_config
Modulefreezer.tests.unit.utils.test_exec_cmd
Modulefreezer.tests.unit.utils.test_utils
Modulefreezer.tests.unit.utils.test_winutils
Modulefreezer.utils.checksum
Modulefreezer.utils.compress
Modulefreezer.utils.config
Modulefreezer.utils.crypt
Modulefreezer.utils.exec_cmd
Modulefreezer.utils.streaming
Modulefreezer.utils.utils
Modulefreezer.utils.winutils
ModuleFreezer is combination for four different components:
Multiprocessing Python software that runs on the client side, where the data backup is to be executed.
It can be executed standalone or by the Freezer Scheduler.
The Freezer Client provides a flexible way to execute backup, restore and other actions on a running system.
In order to provide flexibility in terms of data integrity, speed, performance, resources usage, etc. the freezer agent offers a wide range of options to execute optimized backup according to the available resources as:
A client side component, running on the node where the data backup is to be executed. It consists of a daemon that retrieves the data from the freezer API and executes jobs (i.e. backups, restore, admin actions, info actions,pre and/or post job scripts) by running the Freezer Agent.
The metrics and exit codes returned by the freezer agent are captured and sent to the Freezer API.
The scheduler manages the execution and synchronization of multiple jobs executed on a single or multiple nodes.
The status of the execution of all the nodes is saved through the API.
The Freezer scheduler takes care of uploading jobs to the API by reading job files on the file system. It also has its own configuration file where job session or other settings like the freezer API polling interval can be configured.
The Freezer scheduler manages jobs, for more information about jobs please refer to: freezer_api/README.rst under JOB the sections.
The API is used to store and provide meta-data to the Freezer Web UI and to the Freezer Scheduler. Also the API is used to store session information for multi node backup synchronization. No workload data is stored in the API.
For more information to the API please refer to: freezer_api/README.rst
Web interface that interacts with the Freezer API to configure and change settings. It provides most of the features from the Freezer Agent CLI, advanced scheduler settings such as multi-node backup synchronization, metrics, and reporting.
Back-end used by the API to store and retrieve metrics, metadata sessions information, job status, etc.
Freezer is designed to reduce to the minimum I/O, CPU and Memory Usage. This is achieved by generating a data stream from tar (for archiving) and gzip (for compressing). Freezer segments the stream in a configurable chunk size (with the option –max-seg-size). The default segment size is 64MB, so it can be safely stored in memory, encrypted if the key is provided, and uploaded to Swift as a segment.
Multiple segments are sequentially uploaded using the Swift Manifest. All the segments are uploaded first, and then the Manifest file is uploaded too, so the data segments cannot be accessed directly. This ensures data consistency.
By keeping the segments small, in-memory, I/O usage is reduced. Also as there’s no need to store locally the final compressed archive (tar-gziped), no additional or dedicated storage is required for the backup execution. The only additional storage needed is the LVM snapshot size (set by default at 5GB). The lvm snapshot size can be set with the option –lvm-snapsize. It is important to not specify a too small snapshot size, because in case a quantity of data is being written to the source volume and consequently the lvm snapshot is filled up, then the data is corrupted.
If more memory is available for the backup process, the maximum segment size can be increased. This will speed up the process. Please note that the segments must be smaller then 5GB, since that is the maximum object size in the Swift server.
On the other hand, if a server has small memory availability, the –max-seg-size option can be set to lower values. The unit of this option is in bytes.
The incremental backups is one of the most crucial features. The following basic logic happens when Freezer executes:
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.