Я должен скопировать свой голубой vm?
Для ответа на часть вопроса - нет Ruby не становится скомпилированным ни в какой вид промежуточного основанного на файле байт-кода (в отличие от, скажем, файлов класса Java). Но поскольку Chris сказал, когда рабочие направляющие в производственном режиме действительно необходимо перезапустить процесс для перезагрузки исходного кода.
Одно преимущество использования Пассажира по сравнению с Полукровкой состоит в том, что с Пассажиром можно заставить приложение быть перезапущенным на следующем Запросе HTTP путем выполнения a touch tmp/restart.txt в приложении current/ каталог.
Резервное копирование имеет как минимум две причины:
- Защита от аппаратных сбоев
- Защита от программных ошибок, ошибок человека или злоумышленников
Доверяете ли вы, что MS сделает все необходимое для не потерять ваши данные ни при каких обстоятельствах? Вы уверены, что никогда не совершите ошибку при удалении нужных вам данных или не станете жертвой программной ошибки или атаки? Если нет, вам нужна резервная копия.
Yes.
RAID (disk redundancy, except in the case of RAID0) is not a backup. You still need to protect your files from accidential deletion, corruption, viruses/trojans and so on.
See the following helpful article: http://www.smallnetbuilder.com/nas/nas-features/31745-data-recovery-tales-raid-is-not-backup
Good answers from others. Let me clarify what happens with your Virtual Machine in Azure.
Windows Azure has Blob, Table, and Queue storage. These are all considered durable storage in that every single blob (or table entity, or queue message) is triple-replicated within the datacenter, and beyond that, optionally geo-replicated to neighboring data center (on same continent). Blob writes are replicated instantly; that is, it's not eventual-consistency between spindles. The spindles would also be separated so that they're not all sitting on within the same physical location (that wouldn't be very durable if, say, a disk controller died and took out all 3 disks). Note: Geo-replication is not instant; it's an async operation to the neighboring data center. However: When the writes are performed in the neighboring data center, those writes are written to that data center's blob storage, which is also durable). You don't have access to the geo-replicated data; that's only accessible to Azure, in the event of a catastrophic event at the primary data center.
Your Virtual Machine VHD is stored in a blob, so it benefits from the durable nature of Azure blobs. Also: Any attached drive you create and add to your Virtual Machine is also backed by Blobs (and you may attach 2 x # of cores, up to 16 drives for 8-core box).
Durability aside, you still may want to back up your VM, for reasons already discussed in other answers. To do this, you may take advantage of async blob copy functionality (available in the Azure command line tools as azure vm disk upload). You can also create a blob snapshot, but that doesn't duplicate any data (unless you change individual blob pages, but that's a topic for another day). The blob-copy procedure is the way to go. And within the same data center, this is ridiculously fast. I'm able to copy a Linux VM image in just a few seconds (sometimes less). It will certainly be a slower operation between data centers, but that's to be expected (and I have done this several times).