Jump to content
Covecube Inc.
  • 0

New Pool: Duplicate before adding data or after?


Question

Hi,

I've been doing some shuffling of data to some new drives and installation to a new system. The problem i have is that I've not quite got enough internal disks or system infrastructure in my home environment to simply copy all my data from the old to the new, so I'm having to do it bit by bit (no pun intended). I've come to a minor conundrum; and my question is: is it better to

a. Add 2 empty disks to a pool, turn on duplication and then copy the data to the new pool and let it duplicate as it copies the data to the pool?

or

b. Copy the data to a new single disk, then add another disk to the pool and turn on duplication?

Option b is going to be slightly less risky for me as it means I have less data to shuffle round and am able to another copy of it while I an writing to the new pool. I can then check and make sure there is no issue before wiping the other drive and adding it to the poo, although it might then take a long time to duplicate the data (about 2.5 TB). I suspect option a will be more efficient, as it will simultaneously write to 2 disks, rather than to one then duplicating to another later on, but are there any other issues / pros / cons? Any help greatly appreciated!

Link to post
Share on other sites

Recommended Posts

  • 0

The data copy via duplication when you add a second drive to the pool is extremely fast. Nothing will transfer your data to a second drive faster than this method.

Just be sure to enable duplication as soon as you add the second drive to the pool so that it will start copying the files rather than moving them to balance right away. Then you can also press the >> button so that it goes faster. From my own experience the transfer rates were very good and I was about to duplicate a few TB of data in half a day.

Link to post
Share on other sites
  • 0

Actually, copying to an x2 Pool is faster than copying to an x1 Pool and then duplicating.

Assuming you are going to use (some of) the same HDDs (perhaps alongside other new ones), you could simply:

1. attach them to the new machine

2. Add them to the Pool. THis will NOT delete the existing data on the HDDs. It will only create a hidden PoolPart.* folder

3. Then, disk by disk, MOVE the files from their current location to the PoolPart.* folder. Moving within a HDD is holy crazy fast as it does not do anything but alter the directory, not the files.

This is very fast. Once done, set duplication to x2 and let DP do its magic.

Duplicating does take time but who cares? You can use the machine as it duplicates. Also, you can increase the I/O priority (which does make a difference).

Link to post
Share on other sites
  • 0

Thanks guys; what I neglected to mention was that my set up is in VMs, and as part of my migration I'm changing from hyper-v to ESXi... It's adding a little complication as I need to either convert the vhdx to vmdk or set up one machine with hyper v to copy from and the other in ESXi to receive the copy... Both methods requie twice the amount of space as there is data....

It's like one of those little grid tile puzzles with a single space that you need to shuffle all the pieces around to make the picture!!

Link to post
Share on other sites
  • 0
6 hours ago, Umfriend said:

Actually, copying to an x2 Pool is faster than copying to an x1 Pool and then duplicating.

Assuming you are going to use (some of) the same HDDs (perhaps alongside other new ones), you could simply:

1. attach them to the new machine

2. Add them to the Pool. THis will NOT delete the existing data on the HDDs. It will only create a hidden PoolPart.* folder

3. Then, disk by disk, MOVE the files from their current location to the PoolPart.* folder. Moving within a HDD is holy crazy fast as it does not do anything but alter the directory, not the files.

This is very fast. Once done, set duplication to x2 and let DP do its magic.

Duplicating does take time but who cares? You can use the machine as it duplicates. Also, you can increase the I/O priority (which does make a difference).

I think part of his problem was that he did not have any empty drives or only has a single drive that is currently empty. Yes copying to the x2 pool with real time duplication would be the fastest it would assume that he has already two blank drives which to my understanding he does not.
 

 

5 hours ago, cocksy_boy said:

Thanks guys; what I neglected to mention was that my set up is in VMs, and as part of my migration I'm changing from hyper-v to ESXi... It's adding a little complication as I need to either convert the vhdx to vmdk or set up one machine with hyper v to copy from and the other in ESXi to receive the copy... Both methods requie twice the amount of space as there is data....

It's like one of those little grid tile puzzles with a single space that you need to shuffle all the pieces around to make the picture!!

If you do not have extra space you might need to do this task with duplication off and then after you clear the space by deleting the old VM files you can turn it back on.

So you would need to setup the new machine running your ESXi VM without duplication, if your not going to have enough space, and then transfer the files over.

Remember that as your VM's are individual files they can only rest on a single drive in a normal pool for example if you had 2x 2tb drives in a non-duplication pool you would have 4tb of free space but your vm can not exceed 2TB. This is different than a raid 0 array where your 2x 2tb drives would give you a 4tb limit for the size of your vm. Understanding this limitation is very important. When using drivepool no individual file (in your case the file that contains a VM drive) can never exceed the size of the physical disk it is placed on.

You can get around this by mounting additional VM drives in your environment and splitting up the data.

If you need vmdk files that individually exceed the size of your largest HDD then the only solution that is going to work for you is hardware or software based RAID. Note that you can take things like storage spaces and pool those. For example you could create two raid 0 arrays in storage spaces and then pool those to be a duplication pool. This makes recovery less complicated than a RAID 10 storage spaces implementation.

 

Also keep in mind that duplication and RAID is NOT A BACKUP. Please ensure that you have backups before preceding. IF YOU DO NOT HAVE A BACKUP SOLUTION STOP NOW AND GET ONE.

Link to post
Share on other sites
  • 0
5 hours ago, Umfriend said:

Ahm in that case I'm out. No clue about VMs and vhdx/vmdk etc. I always thought that even when using VMs, you could still have your data on regular NTFS volumes.

You basically have the right idea. In essence all the files stored in the VMs virtual drive is in reality stored in a single vhdx/vmdk file which sits on whatever volume it is on. The issue this creates is that just like any single large file the vhdx/vmdk file can not exceed the size limit of the partition it is stored on.

Link to post
Share on other sites
  • 0
On 10/14/2018 at 11:03 PM, cocksy_boy said:
Quote

a. Add 2 empty disks to a pool, turn on duplication and then copy the data to the new pool and let it duplicate as it copies the data to the pool?

or

b. Copy the data to a new single disk, then add another disk to the pool and turn on duplication?

 

That's pointless.

Just add your original drive to the pool, then MOVE, not COPY your data inside the (hidden) guid folder created by drivepool, then add more drives to your pool, do the some as above, (in case the additional drives are not empty) , then configure the duplication/spanning options in DP, then let DP duplicates/moves your date in background across your drives.

No need to copy huge amount of data on top of the same drive, no space constraints, no need of a temporary landing storage, no huge waste of time and unneeded drives wearing.

Link to post
Share on other sites
  • 0
2 hours ago, zeroibis said:

I think part of his problem was that he did not have any empty drives or only has a single drive that is currently empty. Yes copying to the x2 pool with real time duplication would be the fastest it would assume that he has already two blank drives which to my understanding he does not.
 

Sure. I responded in part to your statement that duplication is fast (which it sort of is but not as fast as copying to an x2 Pool). My suggestion however would not even need empty drives. Just physically move the drives over, add to Pool and then move the files to PoolPart.* folder.

Of course, now that is is VMs, I am clueless. Not sure how VMs/vhdx/DP work together.

Link to post
Share on other sites
  • 0
3 hours ago, zeroibis said:

I think part of his problem was that he did not have any empty drives or only has a single drive that is currently empty. Yes copying to the x2 pool with real time duplication would be the fastest it would assume that he has already two blank drives which to my understanding he does not.
 

 

If you do not have extra space you might need to do this task with duplication off and then after you clear the space by deleting the old VM files you can turn it back on.

So you would need to setup the new machine running your ESXi VM without duplication, if your not going to have enough space, and then transfer the files over.

Remember that as your VM's are individual files they can only rest on a single drive in a normal pool for example if you had 2x 2tb drives in a non-duplication pool you would have 4tb of free space but your vm can not exceed 2TB. This is different than a raid 0 array where your 2x 2tb drives would give you a 4tb limit for the size of your vm. Understanding this limitation is very important. When using drivepool no individual file (in your case the file that contains a VM drive) can never exceed the size of the physical disk it is placed on.

You can get around this by mounting additional VM drives in your environment and splitting up the data.

If you need vmdk files that individually exceed the size of your largest HDD then the only solution that is going to work for you is hardware or software based RAID. Note that you can take things like storage spaces and pool those. For example you could create two raid 0 arrays in storage spaces and then pool those to be a duplication pool. This makes recovery less complicated than a RAID 10 storage spaces implementation.

 

Also keep in mind that duplication and RAID is NOT A BACKUP. Please ensure that you have backups before preceding. IF YOU DO NOT HAVE A BACKUP SOLUTION STOP NOW AND GET ONE.

Thanks - you've hit the nail exactly on the head.... Ive got backups as well and the duplicates for all of the important data - the other is going  to have to risk it for the period when I don't have dupes or backup.... hopefully not too long!

I'm having to have to split the vmdks across the available disks exactly as you suggested.

I think I'll copy the data into a single vmdk and then add a second vmdk at a later stage and turn on duplication when I've confirmed all the data has copied across ok.

Fun times!

Link to post
Share on other sites
  • 0
5 hours ago, t-s said:

 

That's pointless.

Just add your original drive to the pool, then MOVE, not COPY your data inside the (hidden) guid folder created by drivepool, then add more drives to your pool, do the some as above, (in case the additional drives are not empty) , then configure the duplication/spanning options in DP, then let DP duplicates/moves your date in background across your drives.

No need to copy huge amount of data on top of the same drive, no space constraints, no need of a temporary landing storage, no huge waste of time and unneeded drives wearing.

Unfortuantely as the old is in VHDX format and the new is in VMDK (former for Hyper-V and latter for EXSi), they can't both be on a single system at the same time. Otherwise, yes, that would be the perfect way to do it!

Link to post
Share on other sites
  • 0
4 hours ago, Umfriend said:

Sure. I responded in part to your statement that duplication is fast (which it sort of is but not as fast as copying to an x2 Pool). My suggestion however would not even need empty drives. Just physically move the drives over, add to Pool and then move the files to PoolPart.* folder.

Of course, now that is is VMs, I am clueless. Not sure how VMs/vhdx/DP work together.

DP works fine with both VHDX's and VMDKs - the guest operating system just sees them as physical drives and DP works fine - it has been on my system for the last few years. The problem is that VHDX's are incompatible with ESXi and VMDKs are incompatible with Hyper-V, so the migration is tricky!

Link to post
Share on other sites
  • 0
9 minutes ago, cocksy_boy said:

Unfortuantely as the old is in VHDX format and the new is in VMDK (former for Hyper-V and latter for EXSi), they can't both be on a single system at the same time. Otherwise, yes, that would be the perfect way to do it!

There are a number of ways to deal with that.

My own best solution is to mount a vhdx, then use vmware telling to it that it is a physical drive, so you can mix whatever VM from whatever origin, move the data inside them and so on.

Also you can install either ESXi and Hyper-V (or both of them) inside VMware and nest their respective virtual machines (not a task good for low power/low ram machine, but definitely feasible.

Then my favorite one, given almost no one is aware it's possible, you can run Hyper-V and VMware (at the same time) on the same machine if the virtual machines of vmware are 32 bit.

Right now I have Win98 and ThinPC running on VMware and the domain controller running inside Hyper-V

Link to post
Share on other sites
  • 0
9 minutes ago, t-s said:

There are a number of ways to deal with that.

My own best solution is to mount a vhdx, then use vmware telling to it that it is a physical drive, so you can mix whatever VM from whatever origin, move the data inside them and so on.

Also you can install either ESXi and Hyper-V (or both of them) inside VMware and nest their respective virtual machines (not a task good for low power/low ram machine, but definitely feasible.

Then my favorite one, given almost no one is aware it's possible, you can run Hyper-V and VMware (at the same time) on the same machine if the virtual machines of vmware are 32 bit.

Right now I have Win98 and ThinPC running on VMware and the domain controller running inside Hyper-V

Hmmmm - i like your thinking here about nesting the hypervisors / hosts.. I'll have a little think and see if I can work out how to do it with limited disks...! Cheers.

Link to post
Share on other sites
  • 0

@cocksy_boy: So as I said I know nothing about virtualization but can I ask you a question as you appear to be in to this? I always thought that a virtual disk (vhd/vhdx/vmdk) would typically contain an OS and, I guess, apps that are intstalled to run under such OS and that data would not be. But if I understand correctly, you have your data stored in vhdx as well. My question is, why is that better than having data on regular NTFS volumes which could be opened from any VM? Noob here in this area.

Link to post
Share on other sites
  • 0
1 hour ago, Umfriend said:

@cocksy_boy: So as I said I know nothing about virtualization but can I ask you a question as you appear to be in to this? I always thought that a virtual disk (vhd/vhdx/vmdk) would typically contain an OS and, I guess, apps that are intstalled to run under such OS and that data would not be. But if I understand correctly, you have your data stored in vhdx as well. My question is, why is that better than having data on regular NTFS volumes which could be opened from any VM? Noob here in this area.

Caveat: I'm not a virtualisation expert, just a home user who enjoys messing with tech!

Basically, you can pretty much attach as many virtual disks to a VM as you want. I have one virtual drive for the guest OS and then multiple virtual drives based on the various data stores (music, photos, films, documents, etc), and spread across various physical disks using drivepool to give a software RAID-type redundancy, and a separate disk dedicated to backup. It is possible to pass through physical disks directly to virtual machines and cut out the need for a virtual drive, but there are compatibility and other various issues which mean this isn't always the best idea or even possible. You can quickly swap a virtual disk from one VM to another, and depending on the operating system / hypervisor, it can be possible to connect it directly to a desktop PC and access the data on it.

There are lots of advantages of using virtualisation, and specifically a hypervisor like ESXi or Hyper-V Server, is that they take up very little resource overhead on a PC / server set up as a "host". So, a half decent specced server with a decent amount of RAM, processing power, network, and disk space can run multiple operating systems on one hardware. Mine is not quite as advanced as some set ups out there yet, but lots of people run multiple VMs on one host with, for example: virtualised active directory, firewall, web server, backup, SAN, game server, home data server such as FreeNAS / UnRAID, streaming / data sharing etc. As each individual system (usually) only uses a small amount of resource at any one time, they can all be running on one set of hardware at the same time. The beauty is that it is very good for testing: if you want to try a new version of windows, or a new firewall, you just create a new VM, fire it up and play with to work out whether you actually want it or not.

I think it was created primarily to work in large server environments where traditionally each system would be run on a separate physical machine. This is expensive from both set up and running costs (think electricity for power and cooling), and is also means that a lot of the processing power of a single piece of hardware is not used for a large proportion of time. e.g. if you had 4 physical servers that were using 20% of their memory &/or processor power on average, you could covert them all into VMs running on one set of similar hardware with roughly 20% capacity spare. This would save on hardware and running costs and multiply this over many servers then the savings can be big. There's also lots that can be done with redundancy, fall-over, clustering, pooling or resources, its easy to move a VM to another machine and just power it on, etc, etc.

hopefully that's helpful?!

Link to post
Share on other sites
  • 0
2 hours ago, Umfriend said:

@cocksy_boy: I always thought that a virtual disk (vhd/vhdx/vmdk) would typically contain an OS

That's very common, but not the only scenario, you could put al your data in a single VHD, then use it as data disk for your OS, no matter if your OS is tratitional or virtualized.

Quote

and, I guess, apps that are intstalled to run under such OS and that data would not be.

What matters is the path, if you install a program (say in D:\acrobat), and that path is available/reachable, the program will run no matter if D:\ is a whole real disk, a parition inside it, a whole VHD or a partition inside it (you can even nest VHDs for particular purposes).

 

Quote

My question is, why is that better than having data on regular NTFS volumes which could be opened from any VM? Noob here in this area.


NTFS is a filesystem, it's used to format a partition, no matter if it's in a real or virtual disk

Your question should be "why is that better than having data on regular volumes/partitons/HDDs which could be opened from any VM?"

Well, it's not better. There are many advantages and some disadvantages, depending the scenario.

Advantages:

A vhd is very flexible, you can shrink, enalarge, convert it at your liking

You can backup a whole OS or a whole  data VHD just coping a single large file instead of thousands of small ones. No backup SW is needed, no fight with permissions, tens of times faster backup operations and so on.

You can move one or many OS across virtual and/or real machines, just using a file manager.

No need to complicate partitioning operations.

VHD and VHDx (older and newer MS virtual disk formats) can made bootable in a real machine in a couple of clicks. So you can restore a whole OS in 5/10 minutes as long as you have a VHD copy stored somewhere.

Disadvantages:

There is a performance price to pay. Almost unnoticeable in newer VHDXs (supported since Win 8.0)

If you are stupid/distracted enough, you can delete a whole OS (or a whole data disk) in a single click (obviously not from the OS residing inside the VHD itself)

While good choices in the VHD size makes the use of the space more efficient than a traditional partitioning scheme, a bad decision can waste some space available otherwise.

It's possible that a file residing on a (partly) damaged HDD could be easier to recover from a real HDD rather than from a VHD residing on it.

That's more or less summarize the basics of the matter, but is far from being exaustive.

Link to post
Share on other sites
  • 0

I run quite a few VMs and generally best practice is that you want one VM drive that stores your OS and additional ones to store your files. In this way it is simple to spin up another VM of your OS and load your files over there.

If you are not already doing so I would highly recommend splitting your OS vms from your data storage vm files.

The risk with a VM lies in data corruption. In a normal system data corruption may cause a file to be lost. In a VM system file corruption may cause the VM which contains everything to be lost. This is a major risk and is why they are generally used on ZFS volumes and things like ECC ram are used. This is not to say you can not pace them on NTFS as the latest versions actually do a way better job of managing data corruption than in the past but this is where things like raid, snapraid and drivepool etc come in. These things are not just used to help mitigate risk from drive failure but from data corruption as well.

Link to post
Share on other sites
  • 0

So say I have a vhdx file. It is actually a sort of container of many files. Say it is stored on a HDD. Can I transfer the HDD to another machine and retrieve the contents through Windows Explorer?

Say I like regular incremental/differential backups (such as WHS and WSE 2012/2016 provide), would that be possible easily? I mean, I want centralised backups of everything and I would think that then, each vhdx that was changed ever so slighly would have to be backed up entirely each day? I guess I could ensure that each VM has its own backup solution but that seems a bit cumbersome to me. Both to set up but especially to monitor?

The one reason I may be interest in VMs is that I could have a very thin mobile device/laptop, hook it up to two monitors anywhere and RDP into the server for I/O and CPU power. I would not want to RDP into my actual Server OS that runs all the backup, SOHO file sharing and other small Server stuff.

Link to post
Share on other sites
  • 0
Quote

So say I have a vhdx file. It is actually a sort of container of many files.

It's the same as a real HDD, just you dont need a screwdriver to move it around the world

 

Quote

Can I transfer the HDD to another machine and retrieve the contents through Windows Explorer?

Yepp, native MS vhds can be mounted with a doublecklik on them (and dismounted trough the eject menu, just like a DVD)

 

Quote

Say I like regular incremental/differential backups (such as WHS and WSE 2012/2016 provide), would that be possible easily?

Copying a 20/25GB hdd over a 1GB network can be faster than a traditional incremental backup, depending your scenario.

Perhaps the matters aren't said to be mutually exlusive, you can put your whole server folder on a VHD, that can be local or remote, say on a NAS or a different PC/Server. Unlike a traditional mapped  drive, a remote VHD is seen locally exactly the same as a real HDD.

This way you can use a remote disk as WMC cache, you can see it in the disk manager, you can use it on any SW alergic to network drives

Quote

The one reason I may be interest in VMs is that I could have a very thin mobile device/laptop, hook it up to two monitors anywhere and RDP into the server for I/O and CPU power.

That's called VDI, where a remote VM is made available by a single server, very trendy nowadais

Better than a traditional terminal sever because the security you mentioned, because the flexibility, because a single hung VM can be rebooted independently

Worse than a treminal server because you have to install/upgrade each VM just like a real PC, while in terminal server you upgrade/install/backup everithing once, then all users will benefit.

As usual you need the right hammer to bereak a specific nut, as usual there is no "better" and "worse" in absolute. The tool and the infrastructure you need dapends on your needs, your habits, the HW you own and so on.
 

Link to post
Share on other sites
  • 0

OK, I am completely hijacking this thread, sry!

With 20/25GB, I can see that. But what about 3.5TB of data? Currently I backup the entire Server (incl. Client backups) to a HDD that rotates offsite.

Yes, VDI. But really, isn't that simple VM with the intention of RDP'ing into that VM?

Link to post
Share on other sites
  • 0
Quote

With 20/25GB, I can see that. But what about 3.5TB of data?

Sorry but what's the point of having 3.5 TB of data stored locally when you have a Home Server?

Usually you have from 20 to 60 GB dedicated to the OS and its main programs (Office, Photoshop, whatever), perfect for a small SSD or a VHD, then the essential data you need locally in a mechanical HDD, which rarley are more than further 100GB or so, then everithing else is stored safely on a Server/NAS/Cloud and accessed whan you need it.

But even when needed, 3.5GB of data are better managed by a sync SW rather than a traditional Backup.

A traditional backup SWs is a perfect fit to restore an operating system to it's original state (you can't use explorer for that, unless you use a VHD, as discussed earlier).   Copying/syncing  a bunch of random, large files can be done in a huge number of different ways, starting from the good old powertoys or the offline folder feature.

Quote

Yes, VDI. But really, isn't that simple VM with the intention of RDP'ing into that VM?

 Well VDI is a term used by the marketing mumbojumbo, to define a simple VM accessed via a kind remote desktop, not necessarily the MS remote desktop.

But by a larger extension defines also what's behind it, how the machines are managed, how they are backupped, the deduplication of their storage, the live migration of them (you can move a RUNNING VM across different Hyper V servers), and last but not least, how the RAM is managed (a HyperV server can allocate,dynamically, to each VM more ram than the RAM effectively present on the server, just like a Bank does with money of their clients.)

BTW most of those arguments are interesting for a company that whants virtualize 10 or more PCs rather than the signel user who runs one or a couple of VMs at the same time.

Link to post
Share on other sites
  • 0

Uhm, the 3.5TB is located on the (WHS 2011) Server. So I would run WHS2011 or WSE 2016 in one VM under, say, Hyper-V and a VDI/VM alongside. I would then imagine that the OS/Application files are in two vhdx but the actual data on "regular" HDDs (managed by DP in the case of the Server VM). The VDI?VM would also be a Client of the ServerVM and be backup up by it.

Link to post
Share on other sites
  • 0
Quote

I would then imagine that the OS/Application files are in two vhdx but the actual data on "regular" HDDs

Yepp that's an option, but there are many varients limted just by your skill and fantasy.

My old setup was WHS 2011 or its almost identical brother Windows Storage Server 2008r2 Essentials (the latter is better and it's still supported today), installed on a native VHD (booted directly by the bare metal), then I had Hyper-V installed on it (I made the pagages for it). Inside HyperV I had a minimal recent machine, Server Core 2008/2012/1016 with the large storage (and drivepool) installed on it, the Core VM accessed the real, phisical (large) HDDs which where deduplicated by their native feature (and made redundant by Drivepool).

WHS or WSS where also connected to my main TV, running the mediacenter (I made the package for it as well), and acting as a TV server via DVBlink (and/or serverWMC).

Then we succeded to port WMC on W10/WinServer 2012/6 as well, so I switched to a much simpler infrastructure using Win Server 2016 (now 2019).

HyperV is there just to run win2008 server (very small, being the last x86 server), which runs just as a backup domain controller.

The storage is now natively managed by Win Server 2019, which deduplicates them, then duplicated by DP for resiliency (as I wrote elsewhere, sounds like a joke but really it isn't)

So nowadays I don't use the WHS like backup at all. All my OSes are native VHDs (including the server) the large storage is duplicated by drivepool.

All I do is to copy 4/5 vhdx from the ssd to the Pool. (usually I do that one per month after a cumulative update is released and installed.

Link to post
Share on other sites
  • 0

The Hyper-V consolle is present in any W8+ installation (even x86 ones), just enable it from programs and features.

Then connect to a remote one no matter if the HV host has the GUI or not, no matter if paid or free (HyperCore Server).

If you need to manage Server 2008[R2] from Win8+ or viceversa there's a [partly]free SW called 5nine which makes possible the remote administration across different generations of windows.

Other server bits can be managed graphically via the RSAT (remote server administration tool) a package available for free for any windows client OS (except W7/8 embedded)

Or you can just use powershell

 

Quote

Do you have a backup solution as well? 

No, i don't use any old school backup solution at all, I even stopped to enable the essentials role. Once one understands how handy the native vhds are, most of the paradigms from the past looks outdated.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...