I have an existing 2TB drive that's about 1/3 full. I have another 2TB drive that I'd like to add and create a storage pool for redundancy. The only problem is, I can only add the empty drive to a storage pool. Is there any way to create a new storage pool while still preserving my existing data?
Thanks!
tim
There is no way to create a storage pool with existing data. Storage pools are only a collection of drives that are managed by windows. You have to create one or more virtual disks from a storage pool. These virtual disks can be managed as if they are a regular hard drive(format, partitions, filesystem, ...). The data on the virtual disks is saved to the drives associated with the storage pool.
Easy solution:
copy your data to an external hard drive
create storage space with both hard drive
create a virtual disk with mirror
copy your data from the external drive to the virtual disk
complex solution if no additional hard drive is available:
create a storage space with the free hard drive
create a virtual disk(fixed size, simple) with the capacity of your data
copy your data to the created virtual disk
add the second hard drive to the storage pool
create a mirror virtual drive with the remaining capacity of the storage pool
copy the data from the simple virtual drive to the mirrored virtual drive
delete the simple virtual drive
extend the mirror virtual drive to 2 TB
Related
In which folder (or location) should the data be stored in azure VM so that the data is not lost when VM is stopped(deallocated).
If you are using a Windows VM, you can store data on the C: drive without losing data when the VM is deallocated. If you are looking to store a large amount of data, more than is available on the C: drive, you should look at creating an additional disk and attaching that to the VM.
On some VMs there is a temporary/ephemeral drive D: that will get deleted and reprovisioned when you stop(deallocate)/start or redeploy a VM. Do not use this drive for any data that you need to store permanently.
I have deployed a Data Science Virtual Machine on Azure on an N-series instance, which comes with a Standard HDD as the Storage Account Type.
However I would like to include an SSD, but I have not been able to do so.
What I have tried: In the Virtual Machine menu, on Disks, I can attach an extra disk, and create a new one, but it only allows for standard storage disk (HDD) and the option for a premium (SSD) is blocked.
Creating a new storage account I can select a premium storage (SSD), however I cannot link this to my existing VM. This new storage account does not appear between the options when choosing to attach a new disk.
Any help?
Unfortunately the solution is that you may have to use NCv2 or NCv3 which supports premium storage (SSD) and more faster GPU processors (Nvidia P100, V100). Another alternative is to create a separate blob on premium storage and mount that on a Ubuntu DSVM using blobfuse that comes prebuilt into the Ubuntu DSVM. BTW - The NC6 also comes with locally attached temporary storage on SSD (340GB) so you can use it for staging. The data will not presist across reboots. So it is only suitable for work files and will need to be explictly copied to persistent storage. Hope one of these options work for your scenario.
I have a test service fabric deployed to a single node VM. It is all working, but the temporary disk drive is only 20GB is size and keeps running out. I'm only using an A2_V2 Standard instance to keep tests down while we are testing things out.
Service Fabric is using the temporary disk for storage.
Is there a way to increase the size of the temporary disk?
Azure temporary disk size depends on your VM size. If you want to change its size, you need to resize your VM. However, the temporary disk will lost data if you resize the VM. BecauseThe temporary disk is not persisted.
Temporary Disk
The temporary storage drive, labeled as the D: drive is not persisted
and is not saved in the Windows Azure Blob storage. It is used
primarily for the page file and its performance is not guaranteed to
be predictable. Management tasks such as a change to the virtual
machine size, resets the D: drive. In addition, Windows Azure erases
the data on the temporary storage drive when a virtual machine fails
over. The D: drive is not recommended for storing any user or system
database files, including tempdb.
So, I don't suggest you use the temporary disk as the storage for the Service Fabric. You can add data disk to your VM.
I created a Azure Virtual Machine and it in turn created a temporary storage drive for me (D:). Now, If I have C:, D:, E:,F: drive in my VM how can I differentiate which is Azure temporary Storage which is not.
I have tried to Use DeviceType=3 but it lists all the Logical Drives.
I'm assuming you're talking about Virtual Machines (you didn't specify). For VMs:
Your OS disk is backed by durable blob storage. All the time. For Windows, this is approx. 127GB. For Linux, this is approx. 32GB.
Your temp drive is always in-chassis, and at risk. The temp disk size is advertised in the VM sizing specs.
Beyond that: You'd be taking the specific action of mounting additional disks, which are all durable, blob-backed. So you'll know exactly which drives there are.
After some research, it looks there isn't any programmatic way to identify the Azure temporary drive. May be the hack is to look for "DATALOSS_WARNING_README.txt" file in all the drives.
When you create an Azure VM, it creates a D: drive named "Temporary Storage". It's unclear to me just how temporary this is though. Is it reset between reboots, start/stop, or just if the image is recreated? Or arbitrarily? Also, what are some use cases for this temporary storage?
Resets, reboots, fail overs etc. can wipe it. It is only to be used for swap files etc.
Performance Best Practices for SQL Server in Azure Virtual Machines
Temporary Disk
The temporary storage drive, labeled as the D: drive is not persisted and is not saved in the Windows Azure Blob storage. It is used primarily for the page file and its performance is not guaranteed to be predictable. Management tasks such as a change to the virtual machine size, resets the D: drive. In addition, Windows Azure erases the data on the temporary storage drive when a virtual machine fails over. The D: drive is not recommended for storing any user or system database files, including tempdb.
EDIT: Interestingly enough the above has now been updated to the below which says that is OK to store your tempdb on if you are using the D-Series Virtual Machines.
The temporary storage drive, labeled as the D: drive, is not persisted to Azure blob storage. Do not store your data or log files on the D: drive.
Only store tempdb and/or Buffer Pool Extensions on the D drive when using the D-Series Virtual Machines (VMs). Unlike the other VM series, the D drive in the D-Series VMs is SSD-based. This can improve the performance of workloads that heavily use temporary objects or that have working sets which don't fit in memory. For more information, see Using SSDs in Azure VMs to store SQL Server TempDB and Buffer Pool Extensions.
Some Azure Virtual Machine Basics Please
The Temporary storage drive is a local drive on the physical box that should only serve as scratch space. For example, we put the paging file onto this drive to save on transaction costs for each Windows page-in but nothing else. I would recommend you don’t put anything that you need persisted on this drive as it will be deleted upon any hardware failure the system sees whereas the OS disk and any data disks attached will remain persisted in storage even on hardware failures.
This disk is a local disk, non-replicated. If it crashes, anything on it is gone. If your VM is moved to another server, the content is gone. If you scale a VM size down, it's likely this data will be gone, as the allocation size decreases.
As for use cases: Think about database servers that need a scratch disk. Or maybe your workflow involves grabbing content from a blob, processing it, then shipping it off somewhere (e.g. photo/video/audio processing). You could download to temporary storage, do all of your transform work on that disk, then pick up the results, saving the final file somewhere durable. Temp storage use is really open-ended - it's really up to you how you use it; just realize that it's not durable storage (unlike your VHD, which is in durable storage).
When you resize the VM, When you shutdown or restart your VM, when your VM is moved to a different host server(due to service healing, shutdown and restart), when the host is updated, when the host experiences a hardware failure etc.
Source: Azure Pricing page