Adjunct access is a sharing tool that allows you to grant another member SSH and SFTP (and, if you enable it, FTP) access to one of your sites. It also allows them to view some information about the site in our member interface. It does not allow them to modify that information.
If you need more powerful sharing that allows editing site settings, DNS, and other services, account sharing may be a better choice than adjunct membership.
To grant adjunct access to another NearlyFreeSpeech.NET member:
Select the "short name" of the site you want to share; this will take you to the Site Information panel.
Find the "Adjunct Members" box.
Use the "Add an Adjunct Member" button.
Provide the other member's login name on the "Add Adjunct Member" panel.
Confirm with the "Add Member as Adjunct" button.
If you have more than one site, granting a member adjunct access to one site will not enable them to edit any of your other sites.
When the other member does not have a funded account, adding the member to your site confers "Adjunct" status on that member. The member you add must already exist with a confirmed membership.
Adjunct members are not required to pay anything, and their memberships will not expire for non-payment as long as they have adjunct access to at least one site. Of course, they are still entitled to fund an account and create their own sites at any time without restricting their ability to share one or more sites with you.
There is no additional security within a site; any member who has permission to access the site can access or modify any part of the site content. Adjunct access grants full control over the content of your site but not the administration of it. Therefore, they may change or delete all the content on your site, but they cannot remove it from our system, close your accounts, see your balances, or perform any other activity unrelated to site content.
You are solely responsible for providing any support needed by members who do not have an account and a subscription membership with us.
All members must go through the signup process themselves to create their own memberships and agree to our Terms & Conditions of Service; you may not create NearlyFreeSpeech.NET memberships for other people.
We offer a "give us your two cents' worth" free trial to new members. This trial allows people to use many of our services for about a month to help figure out if our service is right for them without the need to make a deposit. However, we have been forced to apply certain limitations and restrictions. Here they are:
NearlyFreeSpeech.NET is not free. The purpose of the "two cents" trial is to help you evaluate our service; it is not for production usage.
Unless you make a deposit, the free trial will eventually expire even if it isn't used. It lasts about a month.
Some system features that are expensive or abuse-prone may be restricted or prohibited on free trial memberships. (Examples include domain registration, email forwarding and sending emails from hosted sites.)
We intend to allow no more than one free trial per person per year, and we may take steps to block or remove people who sign up for multiple free trials to avoid paying for our service.
If we detect abusive or disallowed behavior during the free trial, we will summarily disable or remove the trial membership without warning.
The perks of subscription membership (including individual private support) are not available during the free trial.
We are happy to provide member support to free trial members through our free support options, such as our forum. However, if a question indicates usage not consistent with the intent of the trial offer, we may not be able to assist.
A resource accounting unit (RAU) is a basic unit of web site resource utilization on our network. It is currently defined as a memory usage integral totaling use of one gigabyte of memory for one minute, or the equivalent amount of CPU if a system is CPU constrained.
To provide a simplified example, suppose a single site is running on a dedicated server with 4 gigs of RAM. That server is "worth" 4 RAUs per minute. But if the site is only using half that server's resources (whether RAM or CPU -- whichever is greater since the server is "full" no matter which one runs out first) over a minute, then it would accrue only 2 RAUs during that minute. If the site becomes idle the next minute and has no requests, it accrues no RAUs during that minute.
RAUs are currently used in conjunction with server types that feature resource billing. If you are not using such a server type, RAUs used by your site are ignored and will not be billed. They are still calculated and presented for your information and for our use in capacity planning.
TLS is supported by default for the .nfshost.com name for all newly-created sites (e.g. example.nfshost.com), and can be enabled for older sites from the Site Information panel for that site in our member interface.
For custom aliases, such as www.example.com, you will need a key, a certificate, and (usually) a certificate chain. If you have these already, you can install them through the shell or the member interface, whichever you prefer.
If you don't already have a certificate provider, the most popular option is Let's Encrypt, a free service. The easiest way to use Let's Encrypt certificates is to:
Start an interactive ssh session to our system.
Type the following command:
In most cases, that will set up everything related to TLS for your site using Let's Encrypt certificates, including automatic renewal.
This script handles the most straightforward, most common cases. If your site uses custom web daemons or custom access controls, the automatic scripts may not work for you. For such cases, we provide the dehydrated ACME client; it provides hooks to install and clean up challenges that you can use to interface with whatever you're doing.
tls-setup.sh requires an interactive setup (you have to agree to the Let's Encrypt Terms & Conditions), so you must run it from a live shell session, not via the "Run Shell Command" feature of our UI.
Each account can have an optional alternate emergency contact, which is the email address of someone who you are authorizing to take certain very specific actions related to that account if you are unavailable:
If something is down or disabled and they inquire, we may explain what the problem is and what they may be able to do about it, if anything.
We will help them deposit funds into the account if it is empty or nearly empty. (Nearly empty = below the lowest account balance warning.)
We will allow them to authorize the renewal of expired or nearly expired domains on that account using funds on that account. (Nearly expired = set to "manual renewal" and generating renewal warnings.)
We may allow them to take or authorize other actions necessary to preserve the account or the operability of the services it funds. In cases like this, if we think something fits the spirit of the alternate emergency contact, we will ask both them and you if it should be done, and it will only be allowed if they say yes and you don't respond within a reasonable time depending on the urgency of the situation -- defaulting to 24 hours.
These are the only circumstances where the alternate emergency contact can be used. Alternate emergency contacts cannot: close accounts or request refunds, request inbound or outbound domain transfers, or delete anything. The emergency contact role is limited to preserving what's already there. Even so, human factors and judgment are involved, so you should not make someone an emergency contact unless you trust them and their judgment; you will ultimately be responsible for whatever they do, because you authorized them to do it.
This feature is intended to allow a level of resilience in the case of accounts held on behalf of businesses or customers where the member responsible for the account might go on vacation or otherwise be unavailable when something goes awry. It does not change the ultimate responsibility for the account and its assets at all; specifically, the alternate emergency contact does not create any sort of shared or simultaneous control of the account.
The emergency contact need not be a NearlyFreeSpeech.NET member already, though we may ask them to create a membership if necessary to perform a certain function, like making a deposit.
Do not enter your own email address as the emergency contact. The emergency contact is the person we contact when you are unreachable. Telling us to contact you when you are unreachable serves no purpose.
Storage is billed in terms of megabyte-days. A megabyte-day represents the use of one megabyte of space for a one day period. This means using 31 megabytes for one day is the same as using one megabyte for 31 days. The "Unbilled Storage" numbers displayed on the Account, Site, and MySQL panels are in byte-days. 31 megabyte-days is equal to 32,505,856 byte-days.
The amount of space that your sites and MySQL processes use is measured periodically based on the number of disk blocks they utilize. These blocks are the system default block size, and represent the smallest possible allocation of disk space; even very small files and empty directories require at least one block each. The system then takes the average of that measurement and the prior measurement. The number of megabyte-days is then calculated on a pro-rata basis using the interval between the two measurements.
No. Currently you are not charged for ssh bandwidth usage. That's subject to change at some point, but it would hardly matter as it would take you a very long time indeed to pass a gigabyte of data doing the sort of activities we allow via ssh. For example, if you are editing a web page on an 80x25 terminal, you would have to redraw the entire screen over 530,000 times to get to a gigabyte of traffic.
Because this traffic is negligible, we've never bothered. Of course, if this feature were to start getting abused, we would have to reconsider, but fortunately our members have been very conscientious about their ssh usage.
Each site has a home directory that lives somewhere on our network, called the site root. Inside the site root, there are several subdirectories:
This directory can be used for configuration files that shouldn't be in the public web directory. It can be used to customize PHP or to store configuration files for custom web servers and other daemon processes.
This directory is used for your access and error logs (both current and archived) if you choose to enable them. MySQL logs for a process associated with the site will also appear here, if enabled.
This directory is yours to use for files that you do not want accessible via the web at all. For example, if you're compiling a custom C++ or Go application, putting the source code in this directory would be appropriate. This directory is also your "home" directory for Unix shell purposes.
Files in protected are accessible to scripts and daemons but cannot be directly downloaded over the web. For PHP and CGI applications, this may include libraries, config files, data, or other support files that the scripts in the public folder need to operate. For daemon processes, everything but static content typically goes inside protected.
This directory is the heart of your site. All of the content in this directory is directly accessible via the web. You can put all your static HTML files, images, .htaccess files, and directly-accessed PHP or CGI scripts in this directory.
This directory is for transient (temporary) files, like files uploaded via PHP before they get processed, or for session-handling files.
Old sites may also have a symbolic link from htdocs to public. htdocs is a historical name for the same directory. It is not used by our system.
Resource billing plans charge you based on the amount of resources (currently CPU and RAM) that your site uses. There are two types of resource-based billing: individual and stochastic. For both types, your site will be assessed a charge based on the resource accounting units it accrues.
Most newer sites types (mainly PHP 5.4 and later) support individual resource billing. For these, our system keeps track of the amount of CPU and RAM used by that individual site and generates accounting records based on that usage.
If you have an older site that is not using a resource-billing server type (aka "legacy billing"), its resource usage may still be measured for our internal use in load balancing, so you may see resource usage information in the control panel, but you will not be charged for it. Your storage costs, however, will be considerably higher.
Memberships represent an individual person and as such are non-transferable. Therefore, any kind of transfer will require the recipient to have a membership of their own. Once that is accomplished, there are a couple of different ways to proceed.
Option 1: You can transfer an account in its entirety, which will also transfer all sites, domains, and MySQL server processes funded by that account, using the Transfer an account between memberships assistance request.
Option 2: If the recipient already has an account, you can transfer items such as sites and domains individually from your account to the recipient's account using the Transfer assets between accounts assistance request.
You'll need to make sure you account for the migration of any MySQL data that might be living on a MySQL process you own, but do not wish to transfer to the other member; a site that depends on MySQL will break if it is separated from its database(s). Similarly, if you transfer a site that uses one or more domain names, it is generally necessary to transfer the domain name(s) as well.
In accordance with our policies, the balance of any account transferred between two parties becomes nonrefundable. Also, since we do not allow you to have more than one membership, we will generally not help you transfer assets between memberships if we determine that you control both memberships, unless one of the memberships is being closed as part of the transfer.
Two-factor authentication is a very important method of protecting your membership. We use the OATH method, which is widely supported by two-factor apps, like Google Authenticator and 1Password.
The list of steps below looks formidable, but they're all bite-sized and you'll be through them in no time. There's also plenty of information available along the way; this is more of an overview of what to expect and guidance for how to get the best results.
If you want to secure your site with a certificate that you obtained from a third party for one or more aliases of your site (like example.com and/or www.example.com), that's very straightforward. You will typically need three things, each in PEM format:
A private key (usually generated by you)
A matching certificate (generated by the certificate authority)
One or more intermediate ("chain") certificates (provided by the certificate authority, possibly as a choice of several with the expectation that you will magically know which one is correct)
These will typically be provided in PEM format, frequently with one file for each item. Once you have all three things, there are two very different ways to load them into our system.
First, you can set it up from our website. To do that:
Go to the Site Information panel for your site.
Select the "Upload TLS Files" action in the Action Box.
Paste the PEM-format key, certificate, and intermediate certificates into the text box.
Select the "Set TLS" button.
Alternatively, you can set it up from the command line. To do that:
Make sure all three files are present on your site.
Run a command similar to: cat privkey.pem cert.pem chain.pem | nfsn -i set-tls
In either case, you will see the results of processing the files you submit, and if the processing is successful, it will take effect within about 5 minutes. Applying TLS files is done on a per-alias basis, so if you have multiple aliases secured by different certificates, that is no problem and they will not overwrite each other.
It's also fine if you include extra intermediate certificates or put things in the wrong order; unlike humans, our system can read the files, and will do its best to figure it out for you and assemble (only) the proper ones in the proper order to get things working.
If you need to generate a key and CSR to get a certificate from a third-party certificate authority, you can do that from the command line:
Generate a key by running a command similar to the following:
No. The IP addresses listed for your site in your member control panel may change as part of how our load-balancing system works (although that doesn't happen often) or if a site using a particular IP address suffers certain types of attacks. If this is of concern to you because you are configuring third-party DNS, please see this FAQ entry for instructions.
If you or someone else has cached or is otherwise using an IP address that is no longer listed (perhaps due to not following the instructions above), it is generally not a problem. At any time, any of our dozens of member site IP addresses will provide your site, whether they are listed or not. We will announce if we ever permanently remove any IP addresses from this pool.
We are very sorry to hear that, but we understand that we are not the right environment for everyone. Just select the "Cancel Membership" action on the Profile tab in our member interface to let us know to close your membership and (if applicable) return the remaining balance in your account(s). We'll take care of it. (You must request the closure via this mechanism; to protect your privacy and security, you cannot close your membership via email.)
We will return your remaining funds by the same means you used to deposit them unless that is not possible (e.g. a closed PayPal account or cancelled credit card, or a credit card payment made more than a few months ago). Otherwise, we will offer you the best available options which include sending a check (less a small fee) if you are a US resident, transferring the funds to another member, or donating them to a deserving site or the EFF.
We have a no-hassle cancel policy, so you aren't required to provide a reason for cancelling, but we hope you do. We really appreciate feedback from all our current, former, and future members because that is the only way our service improves. However, if you think there's something we could help you work out to get you to stay, please let us know before you submit a cancellation request. Specifically, please don't use the "reason for cancelling box" to say anything like "if you do XYZ I won't cancel." By the time we respond, some or all of your cancellation may already have been processed. That's a missed opportunity to put things back on the right track, and we hate to see that.
You should only ever have one active membership (because the membership represents "you" as an individual). Creating or accessing multiple memberships is a violation of our Terms and Conditions of Service. Doing so will cause all sorts of problems and may result in substantial additional fees if we have to step in. If you've already done this accidentally, and for some reason, we haven't detected it, please send us Transfer assistance requests from both memberships to consolidate your accounts onto one membership.
Your membership may have multiple accounts if you wish. Each account represents "a discrete pool of money." That's optional; you need at least one account to use our service, but we never require you to have more than one.
The ability to create additional accounts has no technical effects on your hosting. Provided an account balance is positive, you may create and manage as many assets (websites, domains, databases, etc.) as you like funded by that account.
It is solely a convenience feature that allows you to differentiate ownership of funds and assets, help track/control your spending, and share things when multiple people are involved in a project.
Often, this is done for tax, business, or legal purposes, such as:
Separating business and personal services
Segregating expenses if you need to manage services for clients, organizations, etc.
Tracking how much the assets for a specific project cost
Multiple accounts can also be useful if you have one site that is very active or given to surges and another that must always remain available. If both sites are on the same account and the account runs out of funds, both sites will be disabled. If they are on separate accounts, the busy site can never cause the other site to become disabled.
Therefore, you never have to create a second account for yourself to host an additional site, but you do have that option if it suits your needs.
Our service is fully paid in advance; charges (and services) automatically suspend when your account runs out of funds. Under ordinary circumstances, it is not possible to overdraw your account. Here are the least uncommon extraordinary circumstances:
If your usage is just right when your account is depleted, you can wind up with a negative balance of a penny or two. If that happens and you don't want to add additional funds, don't worry. When you cancel, our system will discard the overdrawn amount.
If you are being charged per day for RespectMyPrivacy service, it can overdraw your account. Usually, RespectMyPrivacy is charged per year, but there are two exceptions:
If you have had a registered domain with RespectMyPrivacy service since per-day billing was the norm and you have continuously maintained a low account balance.
If you request RespectMyPrivacy for an inbound transfer of a domain registered for multiple years, and you don't have enough funds to pay for the privacy charges once the transfer completes, it will auto-switch to daily billing.
In either case, the unpaid privacy service can overdraw your account. That is intentional; the consequences of disabling or canceling that service are permanent. Once your information becomes public, reactivating privacy later won't cause people to unsee it or remove it from databases that track whois changes. We would rather lose money than let a brief lapse permanently compromise your privacy.
So, because we do respect your privacy and we know that oversights happen, we won't cancel RespectMyPrivacy service for lack of funds. However, when you hit zero, we will apply the associated charge as a negative balance that you will have to clear before accessing any services. If you leave a balance negative due to unpaid privacy charges for more than 30 days, affected domains may be suspended for having invalid contact information.
The best way to check this is to go to the Account Information panel for the overdrawn account and look at the "Estimated Recurring Activity" box. It will contain a "RespectMyPrivacy Service" line showing how many domains you have with privacy service and how many are prepaid.
Chargebacks can also result in a significant negative balance. You must resolve any chargebacks and related negative balances before you can cancel your membership or access any services paid for by the charged-back funds. ICANN allows chargebacks as one of the few justifications for a registrar to suspend or seize a domain name. We dispute all chargebacks as a matter of policy and take a dim view of people who file them. (Except in cases of credit card fraud, where we take a very dim view of the person using a stolen credit card with our service instead.)
Vanishingly few members will ever see a negative balance. If you do, we hope you will correct it as soon as possible to ensure the successful operation of our services.
Here is a summary of what can and cannot be changed:
NearlyFreeSpeech.NET memberships are held by individuals, must not be shared or transferred, and must use your legal name. (I.e. The name on the government-issued photo ID you would show us to regain access if you ever got locked out.)
If you have legally changed your name (for any reason), you can submit an assistance request to have us update it in the system for you.
If you were interested in changing the name because you want to transfer control of your hosted services to someone else, stop and see this FAQ entry instead. If you're interested in changing the name because someone gave you the login name and password to a membership with their name on it, stop accessing our system immediately! Contact them, and tell them to transfer things to you properly.
You can request a change to your login name at any time for a nominal fee (waived for subscription members) through the same assistance request. No reason is required.
You can add and remove aliases from a site at any time through our member interface.
The short name of a site cannot be changed without creating a new site, moving the content over, then deleting the old one.
The account name can be changed at any time from the Account Information Panel in our member interface.
The account number (e.g. A1B2-C3D4E5F6) cannot be changed.
MySQL process names (DSN's) cannot be changed. You must create a new one, move any needed content, then delete the old one.
MySQL does not provide a builtin way to rename databases, but tables can be renamed using the RENAME TABLE SQL command.
Our system allows the general public to make payments to contribute to the hosting costs of sites hosted on our service. They can use any of the supported payment methods to do so. However, to limit abuse, restrictions apply and there is an approval process for this feature. Contributions can be enabled on a per-site basis. When enabling contributions, you may elect whether or not to set a contribution code that potential contributors will be required to enter. (Use of this code is recommended when the pool of potential contributors is limited to a small, closed community.)
We do impose some strict limitations on you in conjunction with contributions, the largest of which is that you cannot provide anything of measurable value in exchange for contributions. (In other words, you cannot use it as a substitute for eCommerce.) Also, we will not under any circumstances refund to you as cash (or equivalent) any payments made by third parties. Finally, we are very unlikely to accept donations on behalf of members who have not yet funded an account themselves.
It is also possible to use the contribution system if you are a web professional maintaining sites on behalf of a third party who does not have the desire or ability to maintain their own membership on our system. Using the contribution system, they can make payments for the hosting services you are managing for them without having to give you their payment information and without you having to pay us and then seek reimbursement from them.
For complete information about the contribution system, or to request approval, see the relevant assistance request.
We do not recommend this. It is better to delete all your files and reuse the existing site.
If you do choose to delete a site and then create another with the same, we recommend waiting at least fifteen minutes between deleting and creating. If you don't, some parts of our system may get confused and continue to try to access the old (gone) site.
If your site has the wrong short name then you will have to delete it and create another. Short names cannot be changed.
We use your PayPal email address to match your PayPal deposit to your user account. If the email address does not match your contact address, we have to assume that the deposit came from someone else. Since our Terms and Conditions of Service do not allow our service to be used to transfer money from one person to another, we have to regard such deposits as nonrefundable.
If you receive this message because you used an alternate email address, but you are the one who made the deposit from your own PayPal account, you may safely disregard it. This only ever becomes an issue if you request a refund. If your account was funded by a "nonrefundable" PayPal deposit, we'll review it. We're typically able to return a balance remaining from a PayPal deposit to the address it came from.
Most synthetic traffic (i.e. traffic that does not represent a real person or computer making a real request of a service we host) is dropped at the edge of our network due to our advanced network and firewall architecture. This protects our members' services from several types of denial-of-service attacks.
If you attempt to ping something on our network (e.g. your web site) you may get a response. However, this response is a fake generated by our firewall and does not necessarily indicate that your site is reachable. We do sharply limit the number of outbound ICMP ping replies we send at any given time, which can mean your ping requests won't even get fake replies if someone is ping-flooding us; attempts to ping-flood us are very common and completely ineffective, largely because of precautions like these. For that reason, don't assume the (in)ability to ping your site reflects on whether or not it is working properly.
Some traceroute applications, like most under Unix, use UDP packets to probe network hops. These applications will show a "filter prohibited" response (usually "!X") or a routing loop at the edge of our network. Others, most notably the tracert.exe provided with Windows, use ICMP to probe network hops and may be fooled by our fake ping responses. Both results are normal and should not be used as the basis for a problem report.
If you need to traceroute to our network to diagnose an intermediate connection issue, you can use the hostname traceroute.nearlyfreespeech.net for this purpose.
For an accurate measure of your site's performance and availability, you should complete an actual HTTP request to the site, checking both that it responds correctly and how long that response takes. This would be true even if we weren't playing games with ping and traceroute, because overloaded or malfunctioning servers often respond quickly to pings but slowly or not at all to real traffic. Various utilities exist that can be used to test HTTP servers, such as wget, curl, and fetch.
We're delighted to have people refer us to their friends. In fact, we absolutely depend upon it for growth because it lets us focus on building a better service. However, this situation does create a couple of occasional problems that border on heartbreaking for us, so we've created this FAQ entry to offer some guidelines. (Although there are other types of referrals than male friends, we're using the words 'friend' and 'him' here for the sake of simplicity.)
First, and most importantly, you absolutely, positively, must not ever create a membership for anyone other than yourself. Not only are memberships non-transferrable, but you have no legal authority to agree to our TACOS on behalf of a third party. Your friend needs to read, understand, and agree to our TACOS for himself. Those are the rules for using our service, and we don't want people on our system who don't know the rules. Therefore, your friend must complete the signup process for himself.
Second, please make sure that your friend is equipped to manage or maintain his site(s) without ongoing assistance from you. You are not allowed to access other people's memberships! We have gotten into several painful situations because someone "helped" their less tech-savvy friend by setting them up on our service, then disappeared for whatever reason, and the abandoned friend expected us to provide whatever assistance they were promised because no one ever explained the limited scope of support to them. We simply don't have the resources for that, and it invariably winds up with the friend hating us and blaming our "unhelpful support" for not keeping someone else's promises. Please, please, please don't put us in that position. It hurts.
Third, when telling your friend about our service, make sure your friend understands and is comfortable with the scope of our member support. People who are used to lingering on the phone while someone walks them step-by-step through their individual setup sometimes don't appreciate receiving an emailed link to our FAQ when they ask us a basic question. Remember that although you may not need that type of help, some of your friends might. For friends that do, the added cost of a service that provides the extra assistance they need is a very good investment.
What should you do to refer a friend to our service? There are four basic approaches you can choose from, depending on your needs (and those of your friend).
First, you can tell your friend about it and let him do everything himself. This is by far the easiest way to go, and is often the best if your friend is as smart and clever and inclined to do his own thing as you are. (You must be; you picked us!)
Second, you can tell your friend about it, get him to sign up, and then share a site using our adjunct access feature. With this option, he can either create an account and site of his own and make you adjunct, or you can create the site on your membership and make him adjunct. This is the best approach for people who are going to be collaborating on a site.
Third, set up your friend's site, domain, etc on your account and then have your friend create a membership of his own and, when everything is ready, transfer the whole deal to him with a couple of quick support requests. You can either create a second bandwidth account to contain the site and transfer the account between memberships, or your friend can create and fund his own account and you can transfer the relevant bits individually. This is the best approach when you're preparing the site as a gift or favor, but your friend is willing and able to maintain it over the long term.
Fourth, you can create a separate bandwidth account under your membership, use it to fund your friend's site, and manage it all yourself. With this approach, your friend never touches the site personally. This is the best approach for people reselling our service, and for use with friends who want websites of their own but still compulsively forward emails about stolen kidneys and Bill Gates paying email users. ;-)
Again, we are thrilled and grateful to receive all kinds of referrals. We're providing this information solely to help you make sure that any referrals you give work out well for everybody involved.
Visit the Profile pane and, under "Details," verify which email address is the existing one, and which is the pending one. They should both be listed.
Click "Change Email Address" from the "Actions" box.
Enter your existing email address in the "New Email Address" field. Click "Save Changes."
You should be taken to a page that says, "Your request to change email addresses has been cancelled." Click "Click here to continue." You should be returned to the Profile pane and see that your existing address is now the only one listed.
Repeat steps 2 and 3 above to change your address again to a new one, and check your email for a confirmation message. If you do not find it, please be sure to check any spam, junk or trash folders you might have on that account before contacting us for assistance.
Our handling of DMCA notices and the notification-and-takedown process is built around our commitment to treat DMCA notifications as what they are: allegations of copyright infringement, not evidence of copyright infringement. Receiving a DMCA notification does not mean you have done anything wrong.
When you signed up, you agreed to follow our TACOS, and one of the things you agreed to was not to infringe other people's copyright. When you upload content to our service, you assert that you have the right to make that material available. So, on the one hand, we have you, who we have a contract and a relationship with, promising us that your content is legitimate. On the other, we have some random person we've never met who has no relationship with us claiming that it isn't. Under those circumstances, our first inclination is to believe the person we know and trust: you. For that reason, we do not interpret receipt of a DMCA notification as prima facie evidence that you have done something wrong.
However, that's not how the DMCA takedown process works. Our judgment and opinion don't enter into it. By issuing a DMCA takedown notice, the claimant is swearing under penalty of perjury that their claim is true and accurate. For that reason, if a notification meets the legal standard, the law requires us to go through the process, even if the situation looks completely bogus to us. (Unfortunately, civil perjury is a criminal charge, and we're not aware of even one case where a US prosecutor could be bothered to bring that charge in response to an abuse of the DMCA, due in part to the difficulty in proving that the DMCA abuse was intentional and not "an accident.")
Therefore, when we receive a DMCA takedown notice, we will forward it to you in its entirety and give you 24 hours to disable access to the allegedly infringing content it references. "Disabling access" to the content doesn't necessarily mean deleting it, although that is one approach. You could also disable the site, change the file or directory permissions, or temporarily move the allegedly-infringing content to your site's "protected" or "private" directories. It doesn't matter how you do it, but you must remove the content by the deadline, or we will have to do it. Our ability to disable access to content usually entails disabling access to an entire site, whether the entire site is allegedly infringing or not. That sucks if there is only a small amount of allegedly infringing content.
Once you have disabled access to the allegedly infringing content, let us know that you've done so. When you do so, you must indicate which of these three courses of action you wish to take:
You accept the allegation of infringement, and you will not restore the infringing content, file a counter-notification, or make any additional infringing content available in the future.
You do not accept the allegation of infringement, but you do not wish to restore the allegedly infringing content or file a counter-notification.
You do not accept the allegation of infringement and that you intend to file a counter-notification under the Act.
If you do not intend to submit a counter-notification, you may wish to include sufficient supporting justification for us to determine whether to hold this incident against you if future allegations arise, as repeated infringement is grounds for adverse termination of your service (as required by US law).
If you don't respond, or if you respond indicating that you intend to file a counter-notification and then don't follow through within two weeks, we will assume you accept the allegation of infringement.
The rest of this FAQ assumes you are filing the counter-notification.
Your counter-notification must be in writing and must contain the following elements, or we will reject it:
An identification of the allegedly infringing material and the location at which the material appeared before it was removed or access to it was disabled.
The following statement: "Under penalty of perjury, I have a good faith belief that the material was removed or disabled as a result of mistake or misidentification. I will accept service of process from the person who provided notification under S.512(c)(1)(C) or an agent of such person."
Your name, address, and telephone number.
One of the following two statements.
If your address is in the United States: "I consent to the jurisdiction of Federal District Court for the judicial district in which my address is located."
If your address is not in the United States: "I consent to the jurisdiction of any United States judicial district in which NFSN, Inc. may be found." (For your reference, this will typically be either the Florida Middle District Court in Orlando, FL, or the Delaware District Court in Wilmington, DE. Both are US Federal District Courts.)
Your physical or electronic signature.
The best ways to submit your counter-notification are email or fax. If you use email, make sure you're sending a scanned copy that shows your physical signature or a PGP-signed email with a signature that can be correlated to your member contact email address.
We are legally required to provide a copy of your counter-notification to the claimant. This means they will know who you are. If you don't want them to be able to identify you, the counter-notification is not an option you can use.
The claimant then has ten days after receiving the counter-notification from us to file an action against you in the appropriate court seeking a court order to restrain you from engaging in infringing activity relating to the allegedly infringing material and notify us that they've done so. If they do not, we will restore access to the material. (In a case where you disabled access yourself, we will restore access to the material by notifying you when it is OK to restore it. Do not under any circumstances restore access to the allegedly infringing content or make it available at a new location without that notification; that'll result in automatic adverse termination of your service.)
This FAQ entry provides general guidance about our DMCA notification takedown and putback processes. It is not a substitute for legal advice. While we encourage everyone to stand up to copyright bullies and push back when the DMCA process is abused, the consequences of filing a spurious counter-notification can be significant. We strongly urge you to consult a legal professional if you find yourself in this situation.
You can get the full text of the Online Copyright Infringement Liability Limitation Act portion of the DMCA here.
Maintenance mode is a way to disable web access to your site while leaving SSH (and FTP, if enabled) access available. It is suitable for use when you need to edit your site, but you don't want people accessing it while you do, for example if you find out you urgently need to apply a security update to a software package you are using for which an exploit is already available, or if you just don't want people accessing the site while you are in the middle of making major changes to it.
If we discover a problem with your site, such as if it is being exploited to send spam due to a vulnerability in software you are running, we will frequently convert your site to maintenance mode to stop the spam outbreak but leave the site accessible to you so you can fix the problem. Once the problem is fixed, you can bring the site back online yourself. (But if we shift your site to maintenance mode, please make sure you solve whatever problem required us to do that before you bring it back online; we have other ways of disabling sites that our members cannot reverse on their own, and we really dislike being forced to use them.)
The message presented when people attempt to access your site is the same one presented if we perform system maintenance that requires us to take your site offline, and can be seen here, so if you need to work on your site discreetly, you do have the option to put it into maintenance mode and blame us.
To tell the difference, check the Site Information page. If it says the site status is "Member Maintenance" then it is under your control. If it says the site status is "System Maintenance" then we are doing something that requires the site to be offline. (Our system is designed to avoid the need to do this in all but a few rare cases.)
To enter or leave Member Maintenance mode, use the relevant link in the "Actions" box on the Site Information page for the site you want to affect. System Maintenance mode is controlled by our system. Your site status will change automatically to this status when such maintenance starts, and change back once the maintenance is complete.
There is a third type of maintenance mode, called "Restricted Maintenance." Most members never encounter this, but when a site has a bad track record of problem behavior (e.g. being hacked to send spam) and the site operator demonstrates unwillingness or inability to resolve the issue, the site will be placed in this mode. There are two ways to get a site out of restricted maintenance: delete it or, if you are a subscription member, open a support issue explaining what you have done to resolve the problem and asking for the site to be reviewed.
We provide two separate sharing options that are very different in terms of power and scope.
The less powerful option is adjunct access. This lets one member of our service share SSH and SFTP access to a site with another member. This is a good option if you just have someone helping you develop the content of one site.
The more powerful option is account sharing. This lets a member share full access to an entire account and all of its contents with another member. This option is suitable for companies and organizations that can't have just one person who has the ability to manage content, or for shared responsibility, for example where one person is primarily paying the bills and someone else is primarily managing the services.
If your bank says your credit card was charged after our system told you the address or security code were incorrect, that is a temporary issue on your bank's end.
Your bank will automatically resolve the issue in a few days.
There is nothing you or we can do to speed that process up.
The longer explanation:
If you enter your card billing address or card verification code incorrectly (as determined by your bank, not by us), we may not be able to accept the transaction. However, the bank that issued your card may place an authorization hold in the amount of the deposit anyway, just because we tried.
These temporary holds often show up in online summaries as "pending activity" or similar. However, your bank will automatically remove them after some period, usually a few days. Only the transactions that we accept and credit to your account will ultimately be charged to your credit card balance.
Some banks clearly display pending charges as separate from settled charges. Other banks do not. If you contact your bank, their customer support may incorrectly claim that the charge is not pending; i.e. that it has been fully processed. It appears to be exceedingly rare for them to be properly trained on the intricacies of credit card transaction processing. Please note that no credit card transaction is fully processed until it is settled in a daily batch in the middle of the following night.
Since such holds are placed by your card-issuing bank, they are entirely beyond our control. We cannot remove them, nor can we accelerate the pace at which your bank removes them. The best way to avoid this situation is to double-check your address information with your billing statement prior to making a deposit, and make sure your card verification code is correct.
Non-production sites are limited to half your total sites (rounded up).
However, to provide maximum flexibility, this limit is not strictly enforced.
If your non-production sites exceed this limit, our system will apply an adjustment charge once per day. This charge equals the number of excess non-production sites multiplied by the difference in daily cost between a non-production site and a production site. It will appear as a charge for "Excess Non-Production Sites" in your account activity and history.
Your total and allowable non-production sites are calculated across your entire membership, not on a per-account basis. E.g., if you have ten sites spread across three accounts, any five sites may be non-production without incurring extra charges.
If you have multiple accounts and excess non-production sites, the charge will be divided proportionally between those accounts. Any remainder will be allocated to an account at random.
If you have many sites eligible for the non-production plan, this charge can eliminate the need to choose some to make production unnecessarily and ensure you are automatically charged the minimum possible for the number of sites you have.
If you prefer to avoid this charge, you can promote your excess sites to a Production plan, consolidate multiple non-production sites with features like per-alias document root, or remove excess Non-Production sites.
If you do log in to our site, the System Status panel consolidates most of your need-to-know information about recent updates and downtimes. If our system appears down, you can also check our offsite status page for updates.
If you want to stay up-to-date without logging in, minor updates and timely information about outages can also be found on our Twitter feed. (If you don't like Twitter, this information is mirrored on our site with more history than the other options offer.)
For more significant updates, our primary mechanism for keeping our members informed is our blog. It is relatively low-traffic and is where all important service announcements about our service will appear.
To help you keep up to date without constantly visiting our blog, we offer a couple of useful RSS feeds. There is an RSS feed for the whole blog as well as sub-feeds for News & Announcements, Network Status and Policy Changes that include various announcements about service-affecting maintenance, planned downtimes, and changes to the service that affect all or nearly all of our members, like upgrades that may not be backwards-compatible.
For more detail, the News & Announcements RSS feed includes all the Network Status announcements as well as posts about new service availability, beta test announcements, pricing changes and the like. (Since we try to include everything from Network Status in News & Announcements, it's generally not necessary to follow both feeds.) The News & Announcements feed is the one used to populate our member home page.
These are our primary channels of communication, so we strongly recommend that you follow one or more of them to stay abreast of events affecting you. We try to keep all these channels low-traffic and relevant.
If you want to support two-factor authentication with more than one device at a time, we suggest using a program like 1Password that can securely distribute your 2FA configuration to multiple devices. It is also possible to configure multiple devices at once with the QR code, but that's much harder to keep track of.
First, we will present the process in brief, as it is very easy and straightforward. After that, we will go into a little bit of detail about why it works the way it does.
Resist the urge for the sender to give the recipient their username and password. That's expressly forbidden by our TACOS and will ultimately cause both of you a lot more expense and hassle than it avoids.
The recipient should create a new membership of their own. (Unless they already have one!)
That's it. The whole process usually takes about five minutes of your time to arrange.
It's very common for expert web developers and designers to use our service to set up and manage accounts, domains, and sites for third parties. The third party might be an individual (like clients, friends or relatives) or a group, club, or company that the person is involved with. (For the sake of simplicity we'll call people who do this "webmasters" and we'll call the third party the "client" for the rest of this FAQ entry.)
From time to time, for various reasons, it becomes necessary to change the responsible party. Maybe a client/designer relationship is ending, or maybe someone is leaving the company or graduating out of a school club. This situation, which is often already delicate enough, does need to be handled with special care.
The very first thing is to be very sure you understand the difference between an account and a membership. It helps this type of transfer a lot if all the relevant assets are bundled up in one account on the current webmaster's membership. Then, it can then be transferred as a single easy piece to the client's membership. (Most people handling hosting for others already manage assets this way anyway for accounting purposes.)
Transferring assets from the developer's membership to the client's membership (whether neatly bundled in one account or not) must be done while following certain very strict rules about NearlyFreeSpeech.NET memberships:
All memberships belong to individuals, not groups, clubs, companies, etc.
Memberships are non-transferrable.
Memberships cannot be created for others.
Memberships must never be shared or accessed by more than one person.
This means that if you are acting as a webmaster for a client, you cannot, for any reason, create or access a membership belonging to them. This specifically includes setting up a new membership on behalf of a client. And they cannot access your membership either. So giving them your login and password information and sailing off into the sunset is right out.
The common question at this point is how a non-technical client is supposed to set up and manage a membership and hosting for themselves. The answer is that they are not. Our service is designed to be used by skilled webmasters, and it's often the case that removing the technical expertise of a professional developer without replacing it with an equivalent is simply not viable. If you find yourself in a situation that would wind up with a NearlyFreeSpeech.NET membership in the hands of someone who won't know what to do with it, stop. That probably means the transfer you need to arrange is to a hosting company that offers a lot of tech support (e.g. telephone tech support) and caters specifically to nonspecialists. That's absolutely fine; there are a large number of such companies. We would much rather that happen, than for someone to end up with a NearlyFreeSpeech.NET member left in the lurch with no idea of what our rules and policies are, or how to use our service.
For this reason, if we detect a transfer request between two memberships that appear to have been accessed by the same person, we will stop the transfer. Depending on the circumstances, we may refuse to process it entirely. But at a minimum, we will contact both parties and ask them to verify their identity and that they submitted their request themselves. We will further ask the recipient to confirm that they personally went through the signup process, that they have read and understood (and agreed to) our Terms and Conditions of Service, that they understand the nature of our service, and that they are comfortable managing their membership and account moving forward without any external assistance (including ours). Only if we're satisfied will we allow the transfer to proceed.
That's a lot of extra hassle. However, it's very simple to completely avoid it: just make sure that the transfer recipient sets up their own membership and that neither the sender nor the recipient ever accesses the other's membership.
For more information on transfers and on helping others get set up on our service, we recommend also reading our FAQ entries about organizations and
Currently, this is done from the ssh command line. Log in to your site via ssh and run one of the following commands.
To remove TLS from one alias (e.g. www.example.com).
YourPrompt$ nfsn unset-tls www.example.com
To remove TLS from all aliases:
YourPrompt$ nfsn unset-tls '*'
This command takes about five minutes to take effect.
This can also be done by removing and re-adding the alias via the UI, but that approach is significantly more disruptive.
Any application software (e.g. WordPress) running on the site may need to be reconfigured as well.
Please note that we do not recommend removing TLS once you've added it. Doing so may cause problems and security warnings for your site, especially if you have at any point used a Strict-Transport-Security header. In general, you should be able to replace an undesired certificate with a new one without removing it first. Therefore, this command is provided for completeness, testing, and non-production sites.
It is not possible to remove TLS for the shortname.nfshost.com name for your site.
Some domain registrars require you to include the IP addresses of our name servers when setting up your domain. Although this list is subject to change at any time for any reason, here are the IP addresses for all the DNS servers which may serve member domains. Be sure to use the correct name servers for your domain.
If (and only if) you are using our secondary DNS service, one of the following name servers may also apply:
Although this is largely up to you to determine, there are two exceptions.
First, if a site generates revenue of any kind, in any amount, it cannot be a non-production site.
Second, the number of non-production sites you can have is limited to half of your sites, rounded up. If you have more than one site, some of them must be production (or critical) sites regardless of what they're used for. If you have too many non-production sites, our system will apply an Excess Non-Production Sites charge to make up the difference.
Beyond those two criteria, it's your decision. If you have a gut instinct that one of the options is best, you're probably right. If you're not sure, look at the restrictions associated with non-production sites, and the additional custom monitoring associated with critical sites. If your top priority is low cost and you can live with the restrictions, your site is probably non-production. If your top priority is stability, your site is probably production. If your top priority is availability at all costs, your site is probably critical.
Sites that people tend to regard as non-production include (but aren't limited to):
Personal blogs and home pages (that don't generate ad revenue)
Personal resume and portfolio sites for people who change jobs every few years
Experiments and "I want to see if I can set up X" sites
Beta/development versions of another (production) site
Future production sites that are under development and not yet available to the public
Sites that people tend to regard as production include (but aren't limited to):
Most public-facing business, club, and organization sites, whether or not they generate revenue
Blogs that show ads or otherwise generate revenue
Resume & portfolio sites for contractors, consultants, gig workers, and other people who expect frequent traffic that leads to paid work
Active forums with many participants
Sites that people tend to regard as critical include (but aren't limited to):
Any site that generates more than about US$100 per month in revenue
Business sites where business operations depend in any way on the availability of the site
But, to reiterate, as long as you maintain appropriate ratios and follow the revenue rule — that non-production sites may not generate revenue — the choice is yours.
Unbilled storage refers to storage space (for sites or MySQL processes) that our system has recorded as used but which hasn't been billed to your account yet.
The usual reason for this is that the unbilled amount is less than a penny; our system won't bill your account for storage until an individual site or MySQL process accumulates at least a penny's worth. This can cause the "Unbilled" amounts on the Account info panel to be higher than one penny if you have more than one site or MySQL process. E.g. if you have two sites on one account and one has 0.6 pennies worth of unbilled storage and the other has 0.8, your account will show 1.4 cents of unbilled storage, but won't bill you for storage until one or the other gets to the whole penny individually.
The other way you can accrue unbilled storage charges is to allow your account to run out of funds. When an account is empty, storage charges won't be applied, but since we don't immediately delete your content when your account goes empty, each site or MySQL process will continue to accrue unbilled storage until one of two things happens: you make a deposit or the site/MySQL process is deleted. Once you make a deposit, unbilled storage charges in excess of a penny will post to your account. If you delete the site or MySQL process before you add funds, or if your membership expires, associated unbilled storage charges will be discarded along with the content.
If you have large sites or MySQL processes and you leave an account empty for a long time, close to the 30 day limit for example, substantial unbilled storage charges may accrue. You should definitely take this into consideration -- and our system will attempt to warn you about it if applicable -- when adding funds to an account, to prevent further disruptions in service.
Account sharing allows multiple members to share access to and control over a single account. This includes actions like making deposits, renewing domains, and editing websites. It is significantly more powerful than adjunct access.
Account sharing is primarily useful for organizations, where more than one person is involved in the day to day operation of its hosting related services, or even where the one person who is usually involved in those day to day operations has the temerity to get sick or go on vacation.
It can also be useful in cases where a non-expert wants to operate a site with the help of an expert. They can share the account so the expert can adjust DNS settings and manage domain registration as necessary to support the site. It likewise supports setups where one person is paying for things and a different person is doing them.
Account sharing is very powerful, and you should always be very careful that you trust any person with whom you share your account. They essentially become co-owners of the account, with full privileges to do whatever they want with it. That includes, but isn't limited to, transferring funds and assets to accounts of their own, deleting things, or transferring registered domains to other providers.
Once each additional person has set up their own membership, then you can share an account with them from the Account Information panel for that account. Just have them give you their login name and add it to the list of "Members Sharing This Account." To remove another member's shared access, click the "Unshare" button next to their name on the list.
Typically the only thing that will stop you from cancelling your membership is a registered domain. Before you can cancel, any domains you have registered through our service must be transferred away
or you have to wait for them to expire and be deleted.
In the Details box, on the Email Address line, select the Edit button.
On the Update Contact Email Address panel, enter your new email address in the New Email Address box.
Select the appropriate type of update. (But if you want to transfer your hosted services to someone else see this FAQ entry instead.
Use the Start Update button to initiate the change.
We will send an email containing a confirmation code to the address you entered. Use the link in that email to confirm your request, or follow the email instructions to enter the confirmation code manually.
Once you confirm the new email address, it will begin working almost immediately.
If you have NearlyFreeSpeech.NET email forwarding set up to forward messages to your contact address, they will be updated by this process. If you have any domains with RespectMyPrivacy, this process will update those as well.
Each deposit generates an email receipt. If you didn't happen to save that email, you can view a record of your deposit by visiting the "accounts" section of our site, selecting the account in question, and then visiting the "Search Account Activity" link in the "Actions" box. (Note that if you made the deposit within the last 12-24 hours, it might be displayed near the bottom of the account information page under "Current Activity.")
We cannot, under any circumstances, print an invoice. Invoices are only used when the amount of goods/services purchased is known prior to payment, which is not the case with a prepaid service like ours. We do offer detailed records of past account activity via our UI which typically provide the same information as would be contained on an invoice.
Generally, no. Most of the buffoonery that calls itself "penetration testing" is just an attempt to compromise the security and/or availability of our service and/or a member site. We take an extremely dim view of that. It's also a federal crime. We respond to unauthorized "penetration testing" just as we would for any other hacking attempt, ranging from blocking source IPs from accessing our network up to and including contacting the relevant authorities, pressing charges, and seeking civil damages if appropriate. If we find that unauthorized penetration testing was done with a member's cooperation or at a member's direction, that membership will be terminated without warning or refund.
If you do wish to engage in authorized penetration testing, it can be arranged, but the cost is considerable and you must meet significant requirements:
You must be a subscription member to even discuss the possibility. If your site is important enough to require penetration testing, you should be a subscription member anyway.
You must submit a detailed written test plan to us and obtain our approval before testing.
You must submit a certificate of insurance demonstrating applicable coverage both for general liability and professional liability / E&O appropriate for the work you will be performing. The certificate must show current coverage with a per-incident limit of at least $1,000,000 and reflect NFSN, Inc. as an additional insured.
You must agree in writing to share the complete test results with us.
You must schedule all testing at an off-hours time acceptable to us when we can have an engineer available to monitor it. You will be expected to cover all costs associated with that, including overtime, if applicable.
You must provide the source IP address(es) for all testing ahead of time, and should be aware that the engineer monitoring the test will not hesitate to block them if any test activity negatively impacts any site other than the one being tested. You should also anticipate that every packet will be logged.
If you fail to abide by these requirements, or agree to them and fail to follow them (for example if you test outside approved hours, deviate from the approved test plan, or fail to provide results after performing a test), then authorization for future tests is unlikely to be granted.
These requirements are onerous, and reflect that penetration testing is a risky practice that must only be undertaken by skilled, qualified professionals after careful planning. (And yes, people with legitimate need can and do meet these requirements.) If the firm you hire to perform the test balks at these requirements, they are not qualified. If you have a legitimate need, please feel free to contact us; we can direct you to qualified firms.
If these requirements are too onerous, or if the cost is too high (which would be odd; while substantial by our standards, they will be a rounding error compared to the cost of having a proper test performed), that is a good sign that your site is not appropriate for penetration testing.
We do regularly perform and have others perform penetration tests on our own network in order to ensure that our service is as secure as possible. No accesses to member web sites are performed by these tests, but representative sites managed by us are thoroughly tested in addition to our own production sites.
Select the "Transfer Funds Between Accounts" action from the Actions box.
Select the "To another member's account" transfer type.
Enter the recipient's account number in the "Destination Account" text box.
Complete the transfer.
By default, our system includes two low-balance warnings for each account: one at $5.00 and one at $1.00. When your balance falls below a warning level, an email will be generated to your member contact email address. Once a balance warning has been triggered, it will not trigger again until the balance has exceeded the level of the warning for at least one minute.
Because one size does not fit all, account balance warnings are fully customizable. You can set up as many balance warnings as you want, at any level you want up to your current balance, and configure whether they are sent by email or, if you have set an SMS number on the Profile tab, by both email and SMS.
You can also remove the default warnings if you want, although we strongly recommend against doing so unless and until you add other warnings that you feel better suit your expected usage.
To calculate good intervals for warning levels, we recommend that you review your use of our service after a few months and figure out about how much it is costing per week and per month, then set at least two reminders: one when your remaining balance should last about another month, and one when it should last about another week. Then, we advise that you maintain a balance high enough to keep both warnings active at all times; the second, lower warning should serve as a fallback if you forget about or miss the first one. But this is just a recommendation; you are free to manage your warnings however you want.
As a last-ditch reminder, our system will also contact you by email (and SMS if configured) when your account runs completely out of funds. This message cannot be configured or disabled.
No, we do not. Our service is pay-for-what-you-use in nature and each member is responsible for all fees their use of our service incurs. We cannot provide credits or refunds after the fact for services that were provided as configured by the member.
We have no flexibility in this area; all of our vendors charge us on exactly the same terms.
We hate for that to happen; maintaining high-quality documentation is very important to us. Occasionally, however, we slip up. If you find such a mistake please report it to us. We'll check it out and if we agree that it's a typo or mistake in our documentation, and we fix it as a result of your report, we'll give you a $1.00 service credit as a bounty. (Full details can be found on the typo bounty page.)
For site content, we use 3-way mirroring to protect live data, and we take snapshots twice per day. For member MySQL processes, we have less flexibility, but we still take daily full backups of data from each process.
We maintain both local and offsite copies of those backups and age them out on a space-available basis so that, at any given time, we have many viable restore-points available.
We also maintain both live and offsite replicas of the core databases containing member and account data.
Our goal is that in the event of a serious catastrophe that destroyed our primary datacenter, data loss would be limited to everything since the most recent backup, which averages 6 hours for sites and 12 hours for MySQL processes.
However, if we actually had to restore everyone's backups, the amount of data involved is substantial. It would take a really long time, especially if we had to rebuild our infrastructure from scratch first. You might reasonably want access to a copy of your data sooner than we could provide it. We therefore strongly encourage every member to make their own backups.
Yes. Your site will incur storage charges even if it is disabled. (Being disabled doesn't take up any less space.)
Daily site charges also continue to apply unless the site is also set to the "Non-Production" billing plan.
Nothing stops you from converting a Production site to a Non-Production site to avoid the daily charge while disabled. But disabling is really only designed to be an emergency short-term measure, so that is an off-label use. If you want to avoid all charges from a site you know you won't need for awhile, it's best to take a backup and then remove it.