cc_staff
1,486
edits
Backing up your VM: Difference between revisions
no edit summary
No edit summary |
|||
| Line 2: | Line 2: | ||
''Parent page: [[Cloud]]'' | ''Parent page: [[Cloud]]'' | ||
There are a few different strategies to backup your virtual machine and to recover from disasters, which you choose will depend on your requirements and your particular use case. A few common methods to backup or preserve the state of your virtual machine are mentioned followed by an example strategy of how a few of these methods might be used together to create a complete backup strategy. | There are a few different strategies to backup your virtual machine and to recover from disasters, which you choose will depend on your requirements and your particular use case. Creating backups in locations outside the cloud is strongly encouraged. A very common backup rule is the 3-2-1 backup rule, which states that you should have three copies of your data stored on at least two different types of media and one of those copies should be offsite. Below a few common methods to backup or preserve the state of your virtual machine are mentioned followed by an example strategy of how a few of these methods might be used together to create a complete backup strategy. | ||
==File backup== | ==File backup== | ||
| Line 34: | Line 34: | ||
==An example backup strategy== | ==An example backup strategy== | ||
Very large disk images (larger than 10-20 GB) can become difficult to manage with relatively long upload times and long VM creation times. A good basic strategy might be to separate large data sets from your operating system and software stack. The operating system and software stack can be backed up either using a disk image or recreated using some provisioning software (see [[#Setup automation|setup automation]]). The data sets can then be backed up with using normal [[#File backup|file backup]] methods to a remote location. If you are using any database software such as MySQL or PostgreSQL you will want to create dumps of the databases to include in your backups. Finally, and most importantly, '''test restoring from your backup'''. If you can't restore from your backup it isn't | Very large disk images (larger than 10-20 GB) can become difficult to manage with relatively long upload times and long VM creation times. A good basic strategy might be to separate large data sets from your operating system and software stack. The operating system and software stack can be backed up either using a disk image or recreated using some provisioning software (see [[#Setup automation|setup automation]]). The data sets can then be backed up with using normal [[#File backup|file backup]] methods to a remote location. If you are using any database software such as MySQL or PostgreSQL you will want to create dumps of the databases to include in your backups. Finally, and most importantly, '''test restoring from your backup'''. If you can't restore from your backup it isn't very useful. | ||
==See also== | ==See also== | ||