On the heels of the recent PHP updates to our system – the introduction of PHP sockets and the upgrade to v 5.6.0, we have now activated PHP NG on our servers.

PHP NG was first introduced in May, 2014 as a major effort to refactor the PHP codebase in order to reduce memory consumption and to increase overall performance.

Although still in alpha development, PHP NG is starting to show amazing performance improvements over the current stable PHP version – PHP 5.6, while maintaining 100% compatibility.

The tests of developers have shown that PHP 5.7 NG is performing anywhere between 20% and 110% faster than PHP 5.6 in real-world applications such as WordPress, Drupal or SugarCRM. Memory consumption has been reduced significantly too.

Also, PHP NG’s refactored codebase is an excellent basis for future optimizations, and its performance level keeps improving.

PHP 5.7 NG is used only for development purposes and will most probably not be suitable for production use this year. However, it has all the potential to turn into a phenomenon for servers around the world, with more stable betas and even release candidates expected in early 2015.

You can enable PHP NG from the PHP Configuration section of the Web Hosting Control Panel.

PHP NG option in the Control Panel

Semi-dedicated servers in the Australian data centerLast week, our admins were busy configuring server packages in our partnering data centers in Europe – semi-dedicated and OpenVZ VPS packages in Finland and in Eastern Europe, as well as semi-dedicated packages in the UK and in the TelePoint data center in Sofia, Bulgaria.

This week, they added semi-dedicated servers to the data center in Australia, so now you will be able to target a new niche on the Australian hosting market.

Target customers from Australia & the region with more advanced needs

With the addition of semi-dedicated servers to the list of services offered in Australia, you can now expand your reach by addressing the needs of more demanding customers.

From today, site owners who run more complex sites, for example – resource-consuming blogs or traffic-hungry e-stores, will be able to seamlessly move to a more powerful web hosting solution with a click of the mouse.


Since the semi-dedicated servers are based on the same cloud hosting platform that is implemented on our shared hosting servers, an existing shared hosting customer will be able to quickly upgrade to a semi-dedicated server by opening a ticket from their Web Hosting Control Panel. Our technicians will allocate the new extra resources to the customer’s account in a matter of minutes and let the customer know immediately.

The Australian data center – key highlights

SIS Group – the Australian data center that we are partnering with, is located in the business district of Sydney. It is a perfect hosting choice for customers from Australia, New Zealand, the islands of Oceania and Southeast Asia.

The facility relies on redundant high-speed Internet connections and is well-equipped to handle high volumes of traffic from the area and abroad.

Strict temperature and humidity control equipment, water detection systems, security controls and powerful backup power supplies guarantee the continuous flow of customers’ data.

Here’s an overview of the facility’s main advantages:

  • 24×7 Onsite Security
  • Raised Computer Room Flooring
  • Multiple UPS Systems
  • Backup Diesel Generators
  • Dark Fibre Connectivity
  • Fire Protection
  • Video Surveillance
  • Rack Mount Equipment
  • Desktop Equipment
  • Device Monitoring
  • Load Balancing
  • Tape Rotation and Offsite Storage
  • Online Data Backups
  • Remote Hands

The following is a repost of the current wiki data on ZFS from Wikipedia : View current data here


ZFS is a combined file system and logical volume manager designed by Sun Microsystems. The features of ZFS include protection against data corruption, support for high storage capacities, efficient data compression, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs.

ZFS was originally implemented as open-source software, licensed under the Common Development and Distribution License (CDDL). The ZFS name is registered as a trademark of Oracle Corporation.[3][better source needed][4]

OpenZFS is an umbrella project aimed at bringing together individuals and companies that use the ZFS file system and work on its improvements


Data integrity[edit]

One major feature that distinguishes ZFS from other file systems is that ZFS is designed with a focus on data integrity. That is, it is designed to protect the user’s data on disk against silent data corruption caused by bit rot, current spikes, bugs in disk firmware, phantom writes (the write is dropped on the floor), misdirected reads/writes (the disk accesses the wrong block), DMA parity errors between the array and server memory or from the driver (since the checksum validates data inside the array), driver errors (data winds up in the wrong buffer inside the kernel), accidental overwrites (such as swapping to a live file system), etc.

Data integrity is a high priority in ZFS because recent research shows that none of the currently widespread file systems—​such as UFS, Ext,[8] XFS, JFS, or NTFS—​nor hardware RAID provide sufficient protection against such problems (hardware RAID has some issues with data integrity).[9][10][11][12][13] Initial research indicates that ZFS protects data better than earlier efforts.[14][15] While it is also faster than UFS, it can be seen as the successor to UFS.[16][17]

ZFS data integrity[edit]

For ZFS, data integrity is achieved by using a (Fletcher-based) checksum or a (SHA-256) hash throughout the file system tree.[18] Each block of data is checksummed and the checksum value is then saved in the pointer to that block—rather than at the actual block itself. Next, the block pointer is checksummed, with the value being saved at its pointer. This checksumming continues all the way up the file system’s data hierarchy to the root node, which is also checksummed, thus creating a Merkle tree.[18] In-flight data corruption or phantom reads/writes (the data written/read checksums correctly but is actually wrong) are undetectable by most filesystems as they store the checksum with the data. ZFS stores the checksum of each block in its parent block pointer so the entire pool self-validates.[19]

When a block is accessed, regardless of whether it is data or meta-data, its checksum is calculated and compared with the stored checksum value of what it “should” be. If the checksums match, the data are passed up the programming stack to the process that asked for it. If the values do not match, then ZFS can heal the data if the storage pool has redundancy via ZFS mirroring or RAID.[20] If the storage pool consists of a single disk, it is possible to provide such redundancy by specifying “copies=2” (or “copies=3”), which means that data will be stored twice (thrice) on the disk, effectively halving (or, for “copies=3”, reducing to one third) the storage capacity of the disk.[21] If redundancy exists, ZFS will fetch a copy of the data (or recreate it via a RAID recovery mechanism), and recalculate the checksum—ideally resulting in the reproduction of the originally expected value. If the data passes this integrity check, the system can then update the faulty copy with known-good data so that redundancy can be restored.

ZFS and hardware RAID[edit]

If the disks are connected to a RAID controller, it is most efficient to configure it in JBOD mode (i.e. turn off RAID functionality). If there is a hardware RAID card used, ZFS always detects all data corruption but cannot always repair data corruption because the hardware RAID card will interfere. Therefore the recommendation is to not use a hardware RAID card, or to flash a hardware RAID card into JBOD/IT mode. For ZFS to be able to guarantee data integrity, it needs to either have access to a RAID set (so all data is copied to at least two disks), or if one single disk is used, ZFS needs to enable redundancy (copies) which duplicates the data on the same logical drive. Using ZFS copies is a good feature to use on notebooks and desktop computers, since the disks are large and it at least provides some limited redundancy with just a single drive.

There are several reasons as to why it is better to rely solely on ZFS by using several independent disks and RAID-Z or mirroring. For example, a ZFS volume with RAID-0 volumes even with “copies=2” can be failure prone, as the RAID-0 volumes will fail in the event of any disk failures. Thus, storing data on RAID-0 with a ZFS volume and “copies=2” enabled doesn’t increase data reliability, instead, it reduces it.

When using hardware RAID, the controller usually adds controller-dependent data to the drives which prevents software RAID from accessing the user data. While it is possible to read the data with a compatible hardware RAID controller, this inconveniences consumers as a compatible controller usually isn’t readily available. Using the JBOD/RAID-Z combination, any disk controller can be used to resume operation after a controller failure.

Note that hardware RAID configured as JBOD may still detach drives that do not respond in time (as has been seen with many energy-efficient consumer-grade hard drives), and as such, may require TLER/CCTL/ERC-enabled drives to prevent drive dropouts.[22]

Software RAID using ZFS[edit]

ZFS offers software RAID through its RAID-Z and mirroring organization schemes. RAID-Z is invulnerable to the write hole error, which other types of RAIDs suffer from. There are three different RAID modes: RAID-Z1 is similar to RAID 5 (allows one disk to fail), RAID-Z2 is similar to RAID 6 (allows two disks to fail) and RAID-Z3 (allows three disks to fail). The need for RAID-Z3 arose recently because RAID configurations with future disks (say 6–10 TB) may take a long time to repair, the worst case being weeks. During those weeks, the rest of the disks in the RAID are stressed more because of the additional intensive repair process and might subsequently fail, too. By using RAID-Z3, the risk involved with disk replacement is reduced.[23]

Mirroring, the other ZFS RAID option, is essentially the same as RAID 1. The difference is that ZFS allows any number of disks in the mirror, for instance, you could create a mirror consisting of three disks, or even eleven disks.[24]

Resilvering and scrub[edit]

ZFS has no fsck repair tool equivalent, common on Unix filesystems, which does file system validation and file system repair.[25] Instead, ZFS has a repair tool called “scrub” which examines and repairs silent corruption and other problems. Some differences are:

  • fsck must be run on an offline filesystem, which means the filesystem must be unmounted and is not usable while being repaired.
  • scrub does not need the ZFS filesystem to be taken offline; scrub is designed to be used on a mounted, live filesystem.
  • fsck usually only checks metadata (such as the journal log) but never checks the data itself. This means, after an fsck, the data might still be corrupt.
  • scrub checks everything, including metadata and the data. The effect can be observed by comparing fsck to scrub times – sometimes a fsck on a large RAID completes in a few minutes, which means only the metadata was checked. Traversing all metadata and data on a large RAID takes many hours, which is exactly what scrub does.

The official recommendation from Sun/Oracle is to scrub enterprise-level disks once a month, and cheaper commodity disks once a week.[26][27]

Storage pools[edit]

Unlike traditional file systems which reside on single devices and thus require a volume manager to use more than one device, ZFS filesystems are built on top of virtual storage pools called zpools. A zpool is constructed of virtual devices (vdevs), which are themselves constructed of block devices: files, hard drive partitions, or entire drives, with the latter being the recommended usage.[28] Block devices within a vdev may be configured in different ways, depending on needs and space available: non-redundantly (similar to RAID 0), as a mirror (RAID 1) of two or more devices, as a RAID-Z (similar to RAID-5) group of three or more devices, or as a RAID-Z2 (similar to RAID-6) group of four or more devices.[29] In July 2009, triple-parity RAID-Z3 was added to OpenSolaris.[30][31] RAID-Z is a data-protection technology featured by ZFS in order to reduce the block overhead in mirroring.[32]

Thus, a zpool (ZFS storage pool) is vaguely similar to a computer’s RAM. The total RAM pool capacity depends on the number of RAM memory sticks and the size of each stick. Likewise, a zpool consists of one or more vdevs. Each vdev can be viewed as a group of hard disks (or partitions, or files, etc.). Each vdev should have redundancy, because if a vdev is lost, then the whole zpool is lost. Thus, each vdev should be configured as RAID-Z1, RAID-Z2, mirror, etc. It is not possible to change the number of drives in an existing vdev (Block Pointer Rewrite will allow this, and also allow defragmentation), but it is always possible to increase storage capacity by adding a new vdev to a zpool. It is possible to swap a drive to a larger drive and resilver (repair) the zpool. If this procedure is repeated for every disk in a vdev, then the zpool will grow in capacity when the last drive is resilvered. A vdev will have the same base capacity as the smallest drive in the group. For instance, a vdev consisting of three 500 GB and one 700 GB drive, will have a capacity of 4×500 GB.

In addition, pools can have hot spares to compensate for failing disks. When mirroring, block devices can be grouped according to physical chassis, so that the filesystem can continue in the case of the failure of an entire chassis.

Storage pool composition is not limited to similar devices, but can consist of ad-hoc, heterogeneous collections of devices, which ZFS seamlessly pools together, subsequently doling out space to diverse filesystems as needed. Arbitrary storage device types can be added to existing pools to expand their size at any time.[33]

The storage capacity of all vdevs is available to all of the file system instances in the zpool. A quota can be set to limit the amount of space a file system instance can occupy, and a reservation can be set to guarantee that space will be available to a file system instance.

ZFS cache: ARC (L1), L2ARC, ZIL[edit]

ZFS uses different layers of disk cache to speed up read and write operations. Ideally, all data should be stored in RAM, but that is too expensive. Therefore, data is automatically cached in a hierarchy to optimize performance vs cost.[34] Frequently accessed data is stored in RAM, and less frequently accessed data can be stored on slower media, such as SSD disks. Data that is not often accessed is not cached and left on the slow hard drives. If old data is suddenly read a lot, ZFS will automatically move it to SSD disks or to RAM.

The first level of disk cache is RAM, which uses a variant of the ARC algorithm. It is similar to a level 1 CPU cache. RAM will always be used for caching, thus this level is always present. There are claims that ZFS servers must have huge amounts of RAM, but that is not true. It is a misinterpretation of the desire to have large ARC disk caches. The ARC is very clever and efficient, which means disks will often not be touched at all, provided the ARC size is sufficiently large. In the worst case, if the RAM size is very small (say, 1 GB), there will hardly be any ARC at all; in this case, ZFS always needs to reach for the disks. This means read performance degrades to disk speed.

The second level of disk cache are SSD disks. This level is optional, and is easy to add or remove during live usage, as there is no need to shut down the zpool. There are two different caches; one cache for reads, and one for writes.

  • The read SSD cache is called L2ARC and is similar to a level 2 CPU cache. The L2ARC will also considerably speed up Deduplication if the entire Dedup table can be cached in L2ARC. It can take several hours to fully populate the L2ARC (before it has decided which data are “hot” and should be cached). If the L2ARC device is lost, all reads will go out to the disks which slows down performance, but nothing else will happen (no data will be lost).
  • The write SSD cache is called the Log Device, and it is used by the ZIL (ZFS intent log). ZIL basically turns synchronous writes into asynchronous writes, which helps e.g. NFS or databases.[35] All data is written to the ZIL like a journal log, but only read after a crash. Thus, the ZIL data is normally never read. Every once in a while, the ZIL will flush the data to the zpool; this is called Transaction Group Commit. In case there is no separate log device added to the zpool, a part of the zpool will automatically be used as ZIL, thus there is always a ZIL on every zpool. It is important that the log device use a disk with low latency. For improved performance, a disk consisting of battery-backed RAM should be used. Because the log device is written to often, an SSD disk will eventually be worn out, but a RAM disk will not. If the log device is lost, it is possible to lose the latest writes, therefore the log device should be mirrored. In earlier versions of ZFS, loss of the log device could result in loss of the entire zpool, therefore one should upgrade ZFS if planning to use a separate log device.


ZFS is a 128-bit file system,[36] so it can address 1.84 × 1019 times more data than 64-bit systems such as Btrfs. The limitations of ZFS are designed to be so large that they should not be encountered in the foreseeable future.

Some theoretical limits in ZFS are:

  • 248: number of entries in any individual directory[37]
  • 16 exbibytes (264 bytes): maximum size of a single file
  • 16 exbibytes: maximum size of any attribute
  • 256 zebibytes (278 bytes): maximum size of any zpool
  • 256: number of attributes of a file (actually constrained to 248 for the number of files in a ZFS file system)
  • 264: number of devices in any zpool
  • 264: number of zpools in a system
  • 264: number of file systems in a zpool

Copy-on-write transactional model[edit]

ZFS uses a copy-on-write transactional object model. All block pointers within the filesystem contain a 256-bit checksum or 256-bit hash (currently a choice between Fletcher-2, Fletcher-4, or SHA-256)[38] of the target block, which is verified when the block is read. Blocks containing active data are never overwritten in place; instead, a new block is allocated, modified data is written to it, then any metadata blocks referencing it are similarly read, reallocated, and written. To reduce the overhead of this process, multiple updates are grouped into transaction groups, and ZIL (intent log) write cache is used when synchronous write semantics are required. The blocks are arranged in a tree, as are their checksums (see Merkle signature scheme).

Snapshots and clones[edit]

An advantage of copy-on-write is that, when ZFS writes new data, the blocks containing the old data can be retained, allowing a snapshot version of the file system to be maintained. ZFS snapshots are created very quickly, since all the data composing the snapshot is already stored. They are also space efficient, since any unchanged data is shared among the file system and its snapshots.

Writeable snapshots (“clones”) can also be created, resulting in two independent file systems that share a set of blocks. As changes are made to any of the clone file systems, new data blocks are created to reflect those changes, but any unchanged blocks continue to be shared, no matter how many clones exist. This is an implementation of the Copy-on-write principle.

Sending and receiving snapshots[edit]

ZFS file systems can be moved to other pools, also on remote hosts over the network, as the send command creates a stream representation of the file system’s state. This stream can either describe complete contents of the file system at a given snapshot, or it can be a delta between snapshots. Computing the delta stream is very efficient, and its size depends on the number of blocks changed between the snapshots. This provides an efficient strategy, e.g. for synchronizing offsite backups or high availability mirrors of a pool.

Dynamic striping[edit]

Dynamic striping across all devices to maximize throughput means that as additional devices are added to the zpool, the stripe width automatically expands to include them; thus, all disks in a pool are used, which balances the write load across them.

Variable block sizes[edit]

ZFS uses variable-sized blocks, with 128 KB as the default size. Available features allow the administrator to tune the maximum block size which is used, as certain workloads do not perform well with large blocks. If data compression is enabled, variable block sizes are used. If a block can be compressed to fit into a smaller block size, the smaller size is used on the disk to use less storage and improve IO throughput (though at the cost of increased CPU use for the compression and decompression operations).[39]

Lightweight filesystem creation[edit]

In ZFS, filesystem manipulation within a storage pool is easier than volume manipulation within a traditional filesystem; the time and effort required to create or expand a ZFS filesystem is closer to that of making a new directory than it is to volume manipulation in some other systems.

Cache management[edit]

ZFS also uses the Adaptive Replacement Cache (ARC), a new method for read cache management, instead of the traditional Solaris virtual memory page cache. For write caching, ZFS employs the ZFS Intent Log (ZIL). ZFS makes allowances for both of these methods to incorporate separate virtual devices to improve the total IOPS. For read operations it is the “cache” vdev and for write operations it is the “log” vdev.[40]

Adaptive endianness[edit]

Pools and their associated ZFS file systems can be moved between different platform architectures, including systems implementing different byte orders. The ZFS block pointer format stores filesystem metadata in an endian-adaptive way; individual metadata blocks are written with the native byte order of the system writing the block. When reading, if the stored endianness does not match the endianness of the system, the metadata is byte-swapped in memory.

This does not affect the stored data; as is usual in POSIX systems, files appear to applications as simple arrays of bytes, so applications creating and reading data remain responsible for doing so in a way independent of the underlying system’s endianness.


Data deduplication capabilities were added to the ZFS source repository at the end of October 2009,[41] and relevant OpenSolaris ZFS development packages have been available since December 3, 2009 (build 128).

Effective use of deduplication may require large RAM capacity; recommendations range between 1 and 5 GB of RAM for every TB of storage.[42][43][44] Insufficient physical memory or lack of ZFS cache can result in virtual memory thrashing, which can either lower performance or result in complete memory starvation.[citation needed] Solid-state drives (SSDs) can be used to cache deduplication tables, thereby speeding up deduplication performance.[citation needed]

Other storage vendors use modified versions of ZFS to achieve very high data compression ratios. Two examples in 2012 were GreenBytes[45] and Tegile.[46]


With Oracle Solaris, the encryption capability in ZFS[47] is embedded into the I/O pipeline. During writes, a block may be compressed, encrypted, checksummed and then deduplicated, in that order. The policy for encryption is set at the dataset level when datasets (file systems or ZVOLs) are created. The wrapping keys provided by the user/administrator can be changed at any time without taking the file system offline. The default behaviour is for the wrapping key to be inherited by any child data sets. The data encryption keys are randomly generated at dataset creation time. Only descendant datasets (snapshots and clones) share data encryption keys.[48] A command to switch to a new data encryption key for the clone or at any time is provided — this does not re-encrypt already existing data, instead utilising an encrypted master-key mechanism.

Additional capabilities[edit]

  • Explicit I/O priority with deadline scheduling.
  • Claimed globally optimal I/O sorting and aggregation.
  • Multiple independent prefetch streams with automatic length and stride detection.
  • Parallel, constant-time directory operations.
  • End-to-end checksumming, using a kind of “Data Integrity Field“, allowing data corruption detection (and recovery if you have redundancy in the pool).
  • Transparent filesystem compression. Supports LZJB and gzip.[49]
  • Intelligent scrubbing and resilvering (resyncing).[50]
  • Load and space usage sharing among disks in the pool.[51]
  • Ditto blocks: Configurable data replication per filesystem, with zero, one or two extra copies requested per write for user data, and with that same base number of copies plus one or two for metadata (according to metadata importance).[52] If the pool has several devices, ZFS tries to replicate over different devices. Ditto blocks are primarily an additional protection against corrupted sectors, not against total disk failure.[53]
  • ZFS design (copy-on-write + superblocks) is safe when using disks with write cache enabled, if they honor the write barriers. This feature provides safety and a performance boost compared with some other filesystems.
  • On Solaris, when entire disks are added to a ZFS pool, ZFS automatically enables their write cache. This is not done when ZFS only manages discrete slices of the disk, since it does not know if other slices are managed by non-write-cache safe filesystems, likeUFS. The FreeBSD implementation can handle disk flushes for partitions thanks to its GEOM framework, and therefore does not suffer from this limitation
  • Per-user and per-group quotas support.[54]
  • Filesystem encryption since Solaris 11 Express[1]
  • Pools can be imported in read-only mode
  • It is possible to recover data by rolling back entire transactions at the time of importing the zpool.
  • ZFS is not a clustered filesystem; however, clustered ZFS is available from third parties.[citation needed]


  • Capacity expansion is normally achieved by adding groups of disks as a top-level vdev: simple device, RAID-Z, RAID-Z2, RAID-Z3, or mirrored. Newly written data will dynamically start to use all available vdevs. It is also possible to expand the array by iteratively swapping each drive in the array with a bigger drive and waiting for ZFS to heal itself; the heal time will depend on the amount of stored information, not the disk size.
  • As of Solaris 10 Update 11 and Solaris 11.2, it is neither possible to reduce the number of top-level vdevs in a pool, nor to otherwise reduce pool capacity.[55] This functionality was said to be in development already in 2007.[56]
  • It is not possible to add a disk as a column to a RAID-Z, RAID-Z2, or RAID-Z3 vdev. This feature depends on the block pointer rewrite functionality due to be added soon. One can however create a new RAID-Z vdev and add it to the zpool.[57]
  • Vdevs cannot be nested, so a mirror or RAID-Z top-level vdev can only contain files or disks. Mirrors of mirrors (or other combinations) are not allowed.[citation needed]
  • Reconfiguring the number of devices in a top-level vdev requires copying data offline, destroying the pool, and recreating the pool with the new top-level vdev configuration, except for adding extra redundancy to an existing mirror, which can be done at any time or if all top level vdevs are mirrors with sufficient redundancy the zpool split[58] command can be used to remove a vdev from each top level vdev in the pool, creating a 2nd pool with identical data.
  • Resilver (repair) of a crashed disk in a ZFS raid takes a long time. This applies to all types of RAID, in one way or another. This means that future large disks, say 5 TB or 6 TB, can take several days to repair. This means that raidz1 (similar to RAID-5) should be avoided, because repairing a raid puts additional stress on the other disks which might cause them to crash, losing all data in the storage pool if configured as raidz1. Therefore, with large disks, one should use raidz2 (allow two disks to crash) or raidz3 (allow three disks to crash).[59] It should be noted however, that ZFS RAID differs from conventional RAID by only reconstructing live data and metadata when replacing a disk, not the entirety of the disk including blank and garbage blocks, which means that replacing a member disk on a ZFS pool that is only partially full will take proportionately less time compared to conventional RAID.[60]
  • IOPS performance of a ZFS storage pool can suffer if the ZFS raid is not appropriately configured. This applies to all types of RAID, in one way or another. If the zpool consists of only one group of disks configured as, say, eight disks in raidz2, then the write IOPS performance will be that of a single disk. However, read IOPS will be the sum of eight individual disks. This means, to get high write IOPS performance, the zpool should consist of several vdevs, because one vdev gives the write IOPS of a single disk. However, there are ways to mitigate this IOPS performance problem, for instance add SSDs as ZIL cache — which can boost IOPS into 100.000s.[61] In short, a zpool should consist of several groups of vdevs, each vdev consisting of 8–12 disks. It is not recommended to create a zpool with a single large vdev, say 20 disks, because write IOPS performance will be that of a single disk, which also means that resilver time will be very long (possibly weeks with future large drives).



Solaris 10 update 2 and later[edit]

ZFS is part of Sun’s own Solaris operating system and is thus available on both SPARC and x86-based systems.

Solaris 11[edit]

After Oracle’s Solaris 11 Express release, the OS/Net consolidation (the main OS code) was made proprietary and closed-source, and further ZFS upgrades and implementations inside Solaris (such as encryption) are not compatible with other non-proprietary implementations which use previous versions of ZFS.

When creating a new ZFS pool, to retain the ability to use access the pool from other non-proprietary Solaris-based distributions, it is recommended to upgrade to Solaris 11 Express from OpenSolaris (snv_134b), and thereby stay at ZFS version 28.


OpenSolaris 2008.05 and 2009.06 use ZFS as their default filesystem. There are over a dozen 3rd-party distributions, of which nearly a dozen are mentioned here. (OpenIndiana and illumos are two new distributions not included on the OpenSolaris distribution reference page.)


OpenIndiana 148 and 151 use ZFS version 28, as implemented in Illumos.

By upgrading from OpenSolaris snv_134 to both OpenIndiana and Solaris 11 Express, one also has the ability to upgrade and separately boot Solaris 11 Express on the same ZFS pool, but one should not install Solaris 11 Express first because of ZFS incompatibilities introduced by Oracle past ZFS version 28.[62]


OS X[edit]

OpenZFS on OSX (abbreviated to O3X) is an implementation of ZFS for OS X.[63] O3X is under active development, with close relation to ZFS on Linux and illumos’ ZFS implementation, while maintaining feature flag compatibility with ZFS on Linux. O3X implements zpool version 5000, and includes the Solaris Porting Layer (SPL) originally authored for MacZFS, which has been further enhanced to include a memory management layer based on the illumos kmem and vmem allocators. O3X is fully featured, supporting LZ4 compression, deduplication, ARC, L2ARC, and SLOG.[citation needed]

MacZFS is free software providing support for ZFS on OS X. The stable legacy branch provides up to ZFS pool version 8 and ZFS filesystem version 2. The development branch, based on ZFS on Linux and OpenZFS, provides updated ZFS functionality, such as up to ZFS zpool version 5000 and feature flags.[64][65]

A proprietary implementation of ZFS (Zevo) was available at no cost from GreenBytes, Inc., implementing up to ZFS file system version 5 and ZFS pool version 28.[66] Zevo offered a limited ZFS feature set, pending further commercial development; it was sold to Oracle in 2014, with unknown future plans.[citation needed]


Edward O’Callaghan started the initial port of ZFS to DragonFlyBSD.[67]


The NetBSD ZFS port was started as a part of the 2007 Google Summer of Code and in August 2009, the code was merged into NetBSD‘s source tree.[68]


Paweł Jakub Dawidek ported ZFS to FreeBSD, and it has been part of FreeBSD since version 7.0.[69] This includes zfsboot, which allows booting FreeBSD directly from a ZFS volume.[70][71]

FreeBSD’s ZFS implementation is fully functional; the only missing features are kernel CIFS server and iSCSI, but at least the latter can be added using externally available packages.[72] Samba can be used to provide a userspace CIFS server.

FreeBSD 7-STABLE (where updates to the series of versions 7.x are committed to) uses zpool version 6.

FreeBSD 8 includes a much-updated implementation of ZFS, and zpool version 13 is supported.[73] zpool version 14 support was added to the 8-STABLE branch on January 11, 2010,[74] and is included in FreeBSD release 8.1. zpool version 15 is supported in release 8.2.[75] The 8-STABLE branch gained support for zpool version v28 and zfs version 5 in early June 2011.[76] These changes were released mid-April 2012 with FreeBSD 8.3.[77]

FreeBSD 9.0-RELEASE uses ZFS Pool version 28.[78][79]

FreeBSD 9.2-RELEASE is the first FreeBSD version to use the new “feature flags” based implementation thus Pool version 5000.[80]


MidnightBSD, a desktop operating system derived from FreeBSD, supports ZFS storage pool version 6 as of 0.3-RELEASE. This was derived from code included in FreeBSD 7.0-RELEASE. An update to storage pool 28 is in progress in 0.4-CURRENT and based on 9-STABLE sources around FreeBSD 9.1-RELEASE code.


PC-BSD is a desktop version of FreeBSD, which inherits FreeBSD’s ZFS support, similarly to FreeNAS. It also allows installation with disk encryption using geli. Its graphical installer can handle even / (root) on ZFS and RAID-Z pool and Gnome installs right from the start in an easy convenient way (GUI). The current PC-BSD 10.0+ “Joule Edition” has ZFS filesystem version 5 and ZFS storage pool version 5000.


FreeNAS, an embedded open source network-attached storage (NAS) distribution based on FreeBSD, has the same ZFS support as FreeBSD and PC-BSD.


NAS4Free, an embedded open source network-attached storage (NAS) distribution based on FreeBSD 9.2, has the same ZFS support as FreeBSD 9.2, ZFS storage pool version 5000. This project is a continuation of FreeNAS 7 series project.[81]

Debian GNU/kFreeBSD[edit]

Being based on the FreeBSD kernel, Debian GNU/kFreeBSD has ZFS support from the kernel. However, additional userland tools are required,[82] while it is possible to have ZFS as root or /boot file system[83] in which case required GRUB configuration is performed by the Debian installer since the Wheezy release.[84]

As of 31 January 2013, the ZPool version available is 14 for the Squeeze release, and 28 for the Wheezy-9 release.[85]


ZFS has several Linux implementations despite the fact that the GNU General Public License (GPL), under which the Linux kernel is licensed, is incompatible with the Common Development and Distribution License (CDDL) under which ZFS is distributed.[86]According to the used licensing models, a single derived work of both projects cannot be legally distributed, as it is not possible to simultaneously meet both licenses’ requirements.[87] To include ZFS in the Linux kernel, ZFS would have to be cleanly reimplemented, and patents may hamper this.[88]

This problem is being worked around by providing the kernel facilities through a separate kernel module, a technical solution for a legal problem that is also being employed by vendors and distributors of proprietary hardware drivers.

Native ZFS on Linux[edit]

A native port of ZFS for Linux produced by the Lawrence Livermore National Laboratory (LLNL) was released in March 2013,[89][90] with the following key events:[91]

  • 2008: prototype to determine viability
  • 2009: initial ZVOL and Lustre support
  • 2010: development moved to Github
  • 2011: POSIX layer added
  • 2011: community of early adopters
  • 2012: production usage of ZFS
  • 2013: stable GA release.

Of the major distributions, Ubuntu and Gentoo have very good support for ZFS on Linux, meaning that required packages can be installed from their own package repositories, and configuring a ZFS root filesystem is well documented.[92][93] Slackware also provides documentation on supporting ZFS, both as a kernel module[94] and when built into the kernel.[95]

The current zpool version supported by ZFS on Linux is 5000.[96]

Linux FUSE[edit]

Another solution to the issue with licenses incompatibility was to port ZFS to Linux’s FUSE system, so the filesystem runs entirely in userspace instead of being part of the Linux kernel, in which case it is not considered a derived work of the kernel. A project to do this was sponsored by Google’s Summer of Code program in 2006.[97]

KQ InfoTech[edit]

Another native port for Linux was developed by KQ InfoTech in 2010.[98][99] This port used the zvol implementation from the Lawrence Livermore National Laboratory as a starting point. A release supporting zpool v28 was announced in January 2011.[100] In April 2011, KQ Infotech was acquired by sTec, Inc., and their work on ZFS ceased.[101] Source code of this port can be found on GitHub.[102]

The work of KQ InfoTech was pulled back into the native port of ZFS for Linux, produced by the Lawrence Livermore National Laboratory.[101]

List of operating systems supporting ZFS[edit]

List of Operating Systems, Distros and add-ons that support ZFS, the zpool version it supports, and the Solaris build they are based on (if any):

Click here to view the original Wikipedia Post and Available O/S that ZFS supports


Liquid Layer Networks | Cloud Hosting with ZFS


Social Login for Hosting Control Panel - LiquidLayer.net

Social Login for Hosting Control Panel – LiquidLayer.net


Two months ago, we enabled a social login option for all resellers and shared hosting customers.

Now this capability is also available with all semi-dedicated servers, as well as with all Virtual Private Servers and dedicated servers ordered with the Hepsia Control Panel.

Just like on the shared hosting platform, the social login option works with Facebook, Google+ and Yahoo! social media profiles.

This is a very useful one-login solution for users who manage several accounts, since it will save them from having to work with tons of usernames and passwords.

How to use the social login option

The social login option is available with all semi-dedicated servers, since they use the Hepsia Control Panel by default.

VPS and dedicated customers can take advantage of this option if they choose to use the Hepsia Control Panel with their server at signup.

In the Control Panel, users will be able to quickly link their hosting account(s) with their social media profile(s) and thus gain instant access to their Control Panel anytime they open the Login page.

You can find detailed instructions on how to use the social login option in our previous social login post.

Backend improvements to the social login functionality

Apart from enabling the social login option on all Hepsia-equipped servers, our developers have also made a few essential improvements to the functionality’s backend.

Thanks to a tweak to the interface through which we communicate with the social networks, now the connections between the social media profile(s) and the Control Panel will be 3 times faster than before, which means zero waiting time at login.

Also, a glitch causing occasional connectivity hiccups was smoothed out and now users can stay logged in their social media profiles over a truly stable connection.

Semi-dedicated servers and OpenVZ VPSs in  FinlandSince the new data center in Finland was added to our platform, the number of websites hosted on our shared hosting servers there has been growing steadily because of the favourable conditions and the secure image of the facility.

To open up the cool Finnish facility for the more advanced users, we have also added semi-dedicated servers and OpenVZ VPSs to the list of services offered in the Ficolo data center.

Semi-Dedicated Servers in the Finnish Data Center

You and your customers can enable any of the semi-dedicated server packages (Semi-dedicated 1 or Semi-dedicated 2) by selecting the Ficolo data center on the order form:

Semi-dedicated servers in the Finnish data center

Like with the servers in the SteadFast data center in Chicago, USA, a semi-dedicated server in the Ficolo data center will be set up within a few minutes after the purchase.

OpenVZ VPSs in the Finnish Data Center

Тhe Ficolo data center is ready to accommodate all 10 OpenVZ VPS configurations that we are offering. The prices will remain the same:

OpenVZ VPS servers in the Finnish data center

Like with the OpenVZ VPSs in our US, UK and Australian data centers, the virtual machines in the Ficolo data center will be set up within a few minutes after the purchase itself if they are ordered with the Hepsia Control Panel, and within up to 3 hours – if they are ordered with the cPanel Control Panel.

Did you take some time to market the new super-cool Finnish data center to your customers? If you haven’t done so already, here is a short overview of the data center’s advantages:

>> a disaster-proof geographical location – Finland is a country with an extremely low risk of natural disasters like hurricanes, tsunamis, etc.

>> energy efficiency – a decreased amount of energy is needed for cooling purposes due to the facility’s location in a naturally cool network of underground tunnels; the electricity used by the data center is 100% generated by wind power

>> perfect connectivity conditions – direct connections to major fiber-optic network operators like TeliaSonera, Elisa and DNA; for optimum connection speeds, the Internet connections within the country are routed directly to the end customer through the operator’s network, and to international users – through top-level international Internet gateways.

>> maximum data security – a full range of first-class data security solutions, including CCTV surveillance, mantraps, onsite security personnel, firewalls, etc.

Semi-dedicated servers in the UK and in Eastern EuropeThe geographical expansion of our server network continues with the addition of semi-dedicated servers to the data centers in the UK and in Bulgaria.

Now you can offer this custom server hosting solution to a much larger customer base across the globe.

Offering your customers a closer location for their resource-consuming sites will translate into better loading speeds and an amazing website performance.

Semi-dedicated servers in the UK data center

The data center near London, UK, can now accept semi-dedicated server setup requests from you and your customers. It would be a great choice for webmasters from Western and Central Europe and from Africa.

You can enable any of the semi-dedicated server packages (Semi-dedicated 1 or Semi-dedicated 2) by selecting the Pulsant data center on the order form:

Semi-dedicated servers in the UK data center

Semi-dedicated servers in the Bulgarian data center

Our partnering data center in Sofia, Bulgaria, can now also accommodate your resource-heavy sites and apps at the same price. It is a recommended option for users from Eastern Europe and the Middle East.

Again, you and your customers can enable the semi-dedicated server packages by selecting the TelePoint data center on the order form:

Semi-dedicated servers in the BG data center

Semi-dedicated Servers – key service highlights

Here is a list of the key advantages of the semi-dedicated servers, which differentiate them from the other server hosting setups:

  • a guaranteed 99.9% service & network uptime – since the semi-dedicated servers are part of our shared hosting network, they offer a 99.9% service uptime guarantee, not just a 99.9% network uptime guarantee as is the case with the Virtual Private Servers and the dedicated servers;
  • no server management required – our administrators will be taking care of each semi-dedicated server, so you will not be responsible for any server administration duties (monitoring, troubleshooting, maintenance, etc. duties) whatsoever;
  • a free Hepsia Control Panel – our Web Hosting Control Panel comes with each semi-dedicated server by default, so there’s no need for additional setup procedures;
  • instant account setup – a new semi-dedicated server will be set up as quickly as a shared hosting account – right after the payment has been verified by our Sales Department;
  • large CPU quotas – each server will be allocated generous amounts of CPU time, which will empower users to host more resource-intensive sites, including busy WordPress blogs, community portals, e-shops, etc.;
  • large MySQL database query quotas – as with the CPU time, database-heavy website owners can take advantage of large database query quotas;
  • bigger email allocations – semi-dedicated server users can send more emails without an hourly outbound email limit, which gives them more power and flexibility, especially in terms of their email marketing campaigns;
  • a free dedicated IP – each semi-dedicated server will come with a free dedicated IP address, which can be used for SSL setup purposes, for example;
  • free VPN access – 5 GB of free VPN traffic will be ensured for each semi-dedicated server for trouble-free access around the globe;
  • Varnish – this web app accelerator, included with each package, will help users cache their traffic-heavy sites and make them load faster;
  • Memcached – this caching system is also included with each setup and will help users speed up their dynamic applications by reducing database load;
Backup Name Servers - LiquidLayer.net

Backup Name Servers – LiquidLayer.net


The NS records turn a floating domain into a fully functional host by anchoring it to a certain server on the web.

Since the availability of a web server might at times be compromised, most domain names have two name servers – the main one (NS1) and a backup server (NS2), which takes over if the  first one is experiencing problems.

To further secure the customers’ online presence, we’ve also added a second (NS3) and a third (NS4) backup name server to each host

 Most hosting providers provide only two name servers per host

It is a common practice in the web hosting industry hosts to be assigned only two name servers by default. This means that they will have only one backup server, which is usually  located in the same data center. Even if the provider offers more than one backup server, the second one will still be located in the same data center.

This way, if a major problem in the data center’s network occurs, which  is not uncommon in the industry as practice has shown,  the customers’ sites will be left out of the game.  

Thousands of users still keep bitter memories of the major network outage at the EIG’s data center in Provo, Utah, earlier this year, which took many servers down and left their sites offlinein the course of days. EIG keeps customers of leading hosting providers like Hostgator and BlueHost under one roof, so we can all imagine the scope of the issue.

Only users who had their own backup name servers in other data centers, were able to survive the crash.

A location-based name server backup service

We’ve learned from experience that the use of different networks to handle name resolutionwithin one and the same data center is not a solid guarantee for online availability. This is why, our admins implemented backup name servers in three different locations around the globe – NS2  in the Chicago data center (already existing), NS3 in the UK data center and NS4 in the Finnish data center.

This way, in the event of a massive network disruption in the Chicago data center, each next-level backup server will be able to take over the job from the previous one in the chain.

A backup name server (NS3) in the UK data center

While implementing the location-based backup service, our admins first added a name server in the Pulsant data center in Maindenhead, UK.

The UK facility has direct connections to international backbones and a very secure infrastructure. Also, the UK is a country with a lower risk of natural disasters like tsunamis and hurricanes, as compared to the USA.

A backup name server (NS4) in the Finnish data center

We’ve selected the data center in Finland to house the fourth name server for a reason. Located in an underground compound, which used to accommodate the Finnish Defence Forces, the data center can withstand even an atomic bomb attack.

Apart from the natural protection against disasters of all sorts, the facility offers an iron-clad security system, which further guarantees the flawless performance of the sites hosted there.

With the implementation of NS3 and NS4 name servers in different locations, you can now offer your customers a much more stable web hosting service, resistant to network failures and natural disasters, which, as we know, no host is immune to nowadays.

This addition will help you convert those clients of yours who only have a domain into actual hosting customers, since you will offer them triple online protection for their sites – something, which is unthinkable with their current host.

[Fri, 28 Nov 2014] – Thousands of CMS sites threatened by CryptoPHP malware. Learn how to protect your sites.

Our admins located a series of unauthorized attacks on CMS-based sites on our platform over the weekend, which appeared to be part of the CryptoPHP hacker ‘campaign’.

CryptoPHP is a threat that uses backdoored Joomla, WordPress and Drupal themes and plugins to compromise web servers.

This turns out to be a global phenomenon, which was discovered by experts in the Netherlands through a compromised Joomla plugin on a customer’s site.The plugin had been downloaded from a legitimate-looking site that offers a list of free, compromised themes and plugins.

What is the CryptoPHP malware all about?

By downloading and installing pirated CMS themes and plugins on their own sites, users also install the CryptoPHP backdoor, which empowers attackers to exercise remote control over their sites.

The CryptoPHP malware can inject infected content into the compromised sites and even update itself.

However, the main purpose of the malware is to conduct blackhat SEO operations. Experts have detected links and text injected into the compromised pages with the sole purpose of tricking crawlers into giving the hacker sites backlink credit and a pagerank.

Experts have identified thousands of plugins that have been backdoored using CryptoPHP, including both WordPress and Joomla plugins and themes and Drupal themes.

The exact number of websites affected by CryptoPHP has not been determined yet. However, specialists have reasons to believe that they are at least a few thousand.

How are sites on our platform affected by CryptoPHP?

Unfortunately, a few CMS sites on our platform became the target of CryptoPHP hackers as well. Upon locating the attack, our admins made a thorough investigation of the affected sites and found out that they all contain files like ‘social.png’, ‘social0.png’, or ‘social1.png’, etc.  in their code, which are actually PHP scripts instead of PNG files.

They have managed to clean all infected sites of the malware. However, they cannot guarantee that CMS users will not be compromised again if downloading a pirated CMS theme or plugin from the web.

What should I do to make sure I am not affected?

If you have ever installed pirated or untrusted WordPress/Joomla/Drupal plugins/themes/templates, you are potentially susceptible to a CryptoPHP attack.

This is why, you need to take immediate measures and check your sites for files named ‘social.png’. If the file is a PHP script instead of a PNG file, you are probably backdoored.

Also, if you realize that you are infected, you can resolve the problem temporarily by activating the Outgoing Connections Firewall from your Web Hosting Control Panel:

The backdoored sites are trying to make outgoing connections to certain IPs, so this will help you pause the attack until you find a way to resolve the problem.

The best way to protect yourself from the CryptoPHP malware is by making sure you download CMS themes/plugins from from trusted developers’ sites and popular marketplaces.

Here you can find the whole report by the Dutch company, which diagnosed and publicized the CryptoPHP malware:


Jail Host option in the Control PanelNot long ago, we enabled the ModSecurity anti-hack firewall on all our servers to shield your hosting account from malicious online activity around the clock.

As the global practice has shown, however, hackersmay find ways to infiltrate into the systemsurreptitiously (we all know that no one can possibly offer a 100% anti-hacker insurance) and manage to take over one of your hosts. Well, if that happens, it’s time for them to get ‘jailed’ in that host.

Through the new ‘Jail Host’ functionality, our web hosting system will outsmart the intruder by ‘jailing’ them.

What does the ‘Jail Host’ option stand for?

By activating the ‘Jail Host’ option for a given host, you practically isolate it from the other domains within the www/ directory of the same hosting account.

This way, if hackers try to attack the given host, they will be immediately ‘punished’ and ‘jailed’ in that host.

By being ‘jailed’, the intruders will not be able to use the host as a doorway to the rest of the system where the other hosts of yours are located.

This restriction works at the Operating System level, which will guarantee its efficiency in all cases of hack attacks on the given host.

When could I use the ‘Jail Host’ option?

The ‘Jail Host’ functionality can come in real handy when you hire a webmaster to work on your site. If you do not know the webmaster in person, then it would be reasonable to take all measures to protect your host.

In this case, most hosting providers would recommend giving the guy limited FTP access to the particular host. However, if the guy comes with cruel intentions, they will still be able to break the FTP barrier and to litter your account with malicious scripts. If you ‘jail’ the host first, you’ll never risk putting your hosting account as a whole at risk.

How do I activate the ‘Jail Host’ option?

The ‘Jail Host’ option is integrated into the Hosted Domains section of the Web Hosting Control Panel. It is available with all shared hosting plans, semi-dedicated servers and dedicated servers. The option is not available with our Virtual Private Servers because of its incompatibility with the virtualization technology.

In the Hosted Domains section, click on the Edit Host icon at the end of the Actions column:

Jail Host option - Edit Host panel

The ‘Jail Host’ functionality is located at the bottom of the Edit Host form. Just tick the box andclick on the Edit Host button:

Jail Host checkbox  in Hepsia

Does the ‘Jail Host’ option involve any other restrictions?

From a ‘jailed’ host, you will not be able to access the files hosted under a different domain within the same account. So, if you want to use them, you will need to deactivate the ‘Jail Host’ option first.

However, all the other domains in the account will have access to the ‘jailed’ host’s file system.


The ‘Jail Host’’ option helps users address a very specific security glitch, which lies deep under the surface.

Thus, it will add a new level of protection to your customers’ sites and will give you a very strong selling point in the eyes of prospective customers who are sensitive about online security. Actually, who isn’t?

What’s more, ‘Jail Host’ is a completely innovative option on the web hosting market and cannot be currently found readily implemented on any other hosting platform.

So what are you waiting for? Talk to your customers about security in a new and different way.

Base64 attacks are becoming more and more common these days. They involve exploiting a PHP vulnerability on a website and injecting malicious, base64-obfuscated code. The main targets of such attacks are poorly coded plugins that feature security holes.

The encoded code is decoded when the infected .php file is loaded and the actual attack is carried out. A popular attack is to forward a website to another page, which grants the attacker an affiliate bonus.

Here is an example of what a base64 hack looks like in a .php file:

eval(base64_decode(“dGhpcyBpcyBhIHRlc3Q=”)); – this code will output “this is a test” when decoded. A regular base64 code snippet will be significantly longer.

On our web hosting platform, there are several ways to deal with such hacks:

Restore a backup

With our cloud hosting accounts, we offer multiple daily backups, so anyone can easily revert to a previous version of a website with just a click. And we keep backups for up to 30 days.

Here is how to choose the correct backup:

– Log into the Hepsia Control Panel and navigate to the File Manager section;

– Head to the folder pertaining to the hacked website;

– Sort the files by modified date;

This way, anyone can see when the files were last updated. When there are multiple .php files that were updated 10 days ago, simply load an earlier backup with clean versions of those files.

If there are problems restoring a backup, our support team reps will be happy to assist.

Clean the files manually

To clean the files by hand, simply download them to a computer and clean them using a text editor. The Windows/OSX-compatibleSublimeText or the Windows-compatible Notepad++, both of which are available for free, will do a great job.

Once the files are downloaded, load them in the text editor and search for any base64 code. To see if there is any base64 code on the website, use the following search term:


Once you discover an instance, copy the actual code snippet and search again. Simply replace the code with an empty space to get rid of it. If there are still any other base64 instances, repeat the procedure until non are left.

Regular expressions can also be used to target base64 code on the website. Again, simply replace the regex matches with an empty space to clear them from the pages.

Here is a sample regex search term: /eval\(base64_decode\((.*)\)\);/i

Keep in mind that this type of search with target all base64 instances. This means that if any plugin or element of the site is using base64 encoding as well, it will also be removed.

Clean the files over SSH

When using terminal access, all infected files can be cleaned with just a few commands over SSH. If SSH access is not enabled for the account, it can be done with a request in theUpgrades section of the Hepsia Control Panel.

The first thing that needs to be done is to get a sample of the infected base64 code. Use this as a reference for cleaning all infected files.

See which files are infected by using the following command:

$ find . -type f | xargs grep “dGhpcyBpcyBhIHRlc3Q=”

This command will search for all files in the current folder that contain the following string:


Here is how the output of that command will look like:

 ./themes/default/single.php:<?php   eval(base64_decode(“dGhpcyBpcyBhIHRlc3Q=));

./themes/default/search.php:<?php   eval(base64_decode(“dGhpcyBpcyBhIHRlc3Q=”));

This will list all the infected files in the current folder and its subfolders. Once the list is ready, it’s time to eliminate the code.

We’ll use the sed program and our function will look like this:

find . -name “*.php” -print | xargs sed -i ‘s@eval(base64_decode(“dGhpcyBpcyBhIHRlc3Q=”));@@g’

Use the search function one more time to make sure that all the files are now clean. If the search returns no results, the website has been cleaned.

Preventing base64 attacks

As we’ve noted, a base64 hack will target a vulnerability in the code. So the best course of action is to always keep apps and plugins updated to the latest versions available. A good rule of thumb is to only download plugins that are actually needed. If a plugin is not used anymore – remove it from the application.

Also, when downloading new plugins, always keep track of the number of downloads and the update dates. If the last update is more than one year old, the plugin in question may be susceptible to an attack.