Knowledge Base

VPSDime takes metadata backups of Linux VPS plans for disaster recovery purposes. Clients are responsible for their own data. VPSDime shall by no means be responsible for data loss.

Premium VPS have daily backups taken once a night and kept for three days. For Linux VPS, please order the Nightly Backups addon here: https://vpsdime.com/cart.php?gid=addons

For more information regarding Nightly Backups addon, please refer here: https://vpsdime.com/knowledgebase/57_nightly-backups-linux-vps---additional-information

Note: You are still responsible for your own data. We suggest you to keep offsite backups of your important data elsewhere. You can use our sister brand, backupsy.com for your backup needs.

VPSDime offers an optional feature called Nightly Backups that is purchase-able for all virtual machines that are running the OpenVZ containerization technology. You can enable (or disable) this option via the 'Upgrade/Downgrade Configurable Options' menu from the My Services page.

A list of frequently asked questions about this addon is shared below. If you would like information on something that isn't covered by this list, please raise a support ticket.

Q: How often is the backup performed?
A: As the name of the addon suggests, backups are performed once every night.

Q: How many days do you retain a copy of backup for?
A: 3 days

Q: How can we restore from the backups?
A: You will have to raise a ticket from the support area requesting it. At this stage, customers cannot download / restore the backups themselves.

Q: How granular can the restoration request be?
A: Restores can be processed on either files/directories, all databases or complete VPS.

Q: Is there a limit to how many times restoration can be requested?
A: Yes, there is. A customer may request up to 3 times in a month, additional requests will be charged a one-time $10 restoration fee.

Q: I need something that your policies don't cover, what can I do?
A: Please raise a support ticket, we will provide a tailor-made backup strategy just for you.

Q: Should I depend on this backup as a guarantee of my data being intact?
A: Relying on any single backup for complete disaster recovery is usually thought of as a poor strategy. You should take your own backups as well. At least 3 backups of your important data is recommended. VPSDime is NOT responsible for any data loss.

VPSDime backs up ALL premium virtual machines deployed on its infrastructure for free once every night.

A list of frequently asked questions about this service is shared below. If you would like information on something that isn't covered by this list, please raise a support ticket.

Q: How often is the backup performed?
A: Backups are performed once every night.

Q: How many days do you retain a copy of backup for?
A: 3 days

Q: How can we restore from the backups?
A: You will have to raise a ticket from the support area requesting it. At this stage, customers cannot download / restore the backups themselves.

Q: How granular can the restoration request be?
A: We can only restore the whole virtual machine as an atomic unit.

Q: Is there a limit to how many times restoration can be requested?
A: Yes, there is. A customer may request up to 3 times in a month, additional requests will be charged a one-time $10 restoration fee.

Q: I need something that your policies don't cover, what can I do?
A: Please raise a support ticket, we will provide a tailor-made backup strategy just for you.

Q: Should I depend on this backup as a guarantee of my data being intact?
A: Relying on any single backup for complete disaster recovery is usually thought of as a poor strategy. You should take your own backups as well. At least 3 backups of your important data is recommended. VPSDime is NOT responsible for any data loss.

When our payment processor attempts to charge your card, your card issuing bank provides what is effectively a "approve" or "decline" response.

In the event of a "decline" response, there is almost nothing that we can do as it is not within our ability to make or change this determination; you will need to reach out to the bank that issued your card to inquire regarding the reason for the decline. 

The email you received alerting you about the failed payment lists the specific reason for the decline. Below are the most common reasons why transactions are declined when our card processor tries to process your payment.

Your bank placed a hold
The bank or card issuer has placed a hold or other similar measure that prevents the card being charged. Contact your card issuing financial institution to check for any restriction that would prevent payment from being processed successfully.

Your billing information needs updating
The credit card information, or the address you've provided, is inaccurate or incomplete. Your profile details are passed to the credit card processor for authorization, so mismatched details will prevent a successful payment. Also, the credit card might have expired.

Your payment account has insufficient funds
The payment processor was unable to collect payment due to insufficient funds in the account on file. Contact your card issuing financial institution to ensure fund availability.

Your bank does not allow international transactions by default
Your card issuing financial institution may be blocking an international payment processor from successfully authorizing a transaction without your explicit consent, and this may be a default setting pre-determined by your card issuing financial institution. Note that this may be true even if other international transactions work. Contact your card issuing financial institution to check for any restriction that would prevent payment from being processed successfully. Note that even if you clear this with your card issuing financial institution, this may 'reset' at any time by your card issuing financial instituion without warning or notice.

The following ports are blocked/filtered by default, and to preserve network quality, cannot be opened/unfiltered:

22 - ssh - filtered to prevent brute force attacks. Any filtering can be completely avoided by changing your SSH port to any value than the default of 22, and this is a recommended best security practice anyway.

25, 465, 587 - mail submission - monitored for spam emission. Open by default and will be automatically blocked if mass mail is noted by automated systems.

111 - nfs/portmap - blocked, used for reflection attacks. NFS can still be set up with static ports, instructions available in your preferred search engine. SSHFS is the recommended replacement for NFS; it's faster, lighter, more secure with default settings, easier to set up, and handles either end disappearing better than NFS.

161 - snmp - blocked, used for reflection attacks. SNMP can be run on any other port.

389 - LDAP - blocked, used for reflection attacks. LDAP shouldn't be used over the public Internet anyway. Use LDAPS. If your application doesn't support LDAPS, it's a great time to upgrade.  

Regarding any other ports, you need a service listening on that specific port for it to look "open". For example, if you do not have a web server (Apache/nginx, etc) running on port 80, it will appear as closed when you check it via telnet or an online service. This is because there is no service assigned to that port and not because we block it.

If you've recently installed a firewall in your server and have suddenly lost access or after a reboot, you can use the console we provide in the client area to log in and execute the following commands to allow SSH access on the default port. You can use the same actions to allow a different SSH port you've configured in your SSH server config, changing 22 to the port you've selected.

UFW:
ufw allow 22/tcp

CSF: 
Edit /etc/csf/csf.conf with your preferred text editor.
Add port 22 to TCP_IN, following the same formatting already visible in the config file for TCP_IN
Save the file, exit the text editor
Execute: csf -r

Firewalld:
firewall-cmd --permanent --add-port=22/tcp
firewall-cmd --reload

iptables:
iptables -I INPUT -m tcp -p tcp --dport 22 -j ACCEPT

nft (replace "inet" with your nft table name):
nft add rule inet filter input tcp dport 22 ct state new tcp flags \& \(syn \| ack\) == syn counter accept

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for vm.ext.cekkent.net has changed,
and the key for the corresponding IP address 1.2.3.4
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:aE5WznPHvx3jSrGx2JvfqEKHn2OW44/A6zhCSg+7OsI.
Please contact your system administrator.
Add correct host key in /Users/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/user/.ssh/known_hosts:1983
ECDSA host key for vm.ext.cekkent.net has changed and you have requested strict checking.
Host key verification failed.

% ssh-keygen -R test.domain.com
# Host test.domain.com found: line 1983
/Users/user/.ssh/known_hosts updated.
Original contents retained as /Users/user/.ssh/known_hosts.old
%

Proceed as normal thereafter. 

- Disable root login on your SSH service

- Disable password auth and enable key based auth on your SSH service

- Install and configure fail2ban

- Remove unnecessary software

- Always keep your software/scripts updated

- Do not use outdated Kloxo Panel

- Do not use zPanel

- Harden your /tmp (Disable software execution on the partition)

- If you have static IP or you use a VPN, configure your SSH to only allow login from those IPs.

For Windows VPS

- Always keep your Windows updated

- Do not deactivate Windows Firewall and Defender

- If you have static IP or you use a VPN, configure your RDP to only allow login from those IPs.

1. Make it long

Generally longer the password, harder for hackers to guess it. If possible use passwords with at least 15 character long.

2. Avoid common substitutions

Password crackers are hip to the usual substitutions. Whether you use DOORBELL or D00R8377, the brute force attacker will crack it with equal ease.

3. Don’t use memorable keyboard paths

Much like the advice above not to use sequential letters and numbers, do not use sequential keyboard paths either (like qwerty, 123456, etc). These are among the first to be guessed.

4. Don't use names and surnames as password

All single names and surnames are in password crackers' dictionary and they check against these words at first to crack your password.

5. Use multiple words method

The best way to create memorizable passwords is using multiple words together. The following password is easily memorizable and it's fairly strong.

HolyConcreteThrone

You can use a random word generator for this, such as our own at https://vpsdime.com/passwordgen.php

6. Don't add @123 to the end of a word

Adding @123 to the end of a common word doesn't turn a poor choice of a password into a good one. 

7. Use a password creator

If you are using a password manager then you can simply use it to generate strong passwords. Alternatively, you can use websites like https://pw.cekkent.net/ or you can use our own password generator here: https://vpsdime.com/passwordgen.php

To point your domain name to your VPS, you simply need to create an A record pointing your VPS IP on your DNS provider.

An A record is a kind of DNS record which links a hostname to an IPv4 address. So instead of an IP address, you can use a domain name to connect to your web server (Apache, Nginx, Litespeed, etc) of your VPS.

Most of the domain registrars provide free DNS service for your domain.

You can either use your domain registrar's DNS service or you can use 3rd party DNS services such as Amazon Route53, Cloudflare or dns.he.net

Lastly, you may utilize our own DNS hosting service.

1. If you'd like to use your domain registrar, please check the following articles:

For Godaddy

http://support.godaddy.com/help/article/680/managing-dns-for-your-domain-names

For Namecheap:

https://www.namecheap.com/support/knowledgebase/article.aspx/319/2237/how-can-i-set-up-an-a-address-record-for-my-domain

For Hostgator

http://support.hostgator.com/articles/hosting-guide/lets-get-started/dns-name-servers/manage-dns-records-with-hostgatorenom

For Name.com

http://support.name.com/entries/21479548-How-do-I-create-A-records-to-point-to-the-IP-of-my-web-host-

For Network Solutions

http://www.networksolutions.com/support/accessing-dns-manager-advanced-tools/

For others, you can simply do a Google search like: "How to manage DNS <your domain registrar name>"

2. Use Route53, Cloudflare, etc.

Simply go to their support pages to learn about how to create/edit A records.

You'd need to use their provided nameservers on your domain to use their services.

3. Alternatively, you can use your own DNS servers.

The simpliest method for this is installing a control panel such as cPanel, Direct Admin or Plesk and take a look at their support pages.

4. Using VPSDime's DNS Service

Since early October 2021, VPSDime has started offering free DNS hosting service. To use it, please login to your client area and go to DNS Management page at the top menu.

Premium VM is our latest offering relying on Kernel-based Virtual Machine (KVM) technology. It offers quite a lot of advantages when compared with our existing, older Linux VPS lineup.

This article is meant to shed some light on the differences to potential customers looking to make a choice.

If the software is something we provide licenses for, then sure we'll include a free installation.

If it's not then unfortunately, no. We'll guide you to the right direction by pointing out tutorials for you but you'd have to do the work.

We provide generous resources with extremely afforable prices and great uptime for experienced users.

However, in this age of Internet, you can simply educate yourself regarding management of your VPS. The internet is full of resources and we are always here to help.

If you'd like to offload the server management, then you can find full or half time server administrators on Freelancer, Web Hosting Talk forums, etc.

Our service is designed for experienced users and is self-managed. We are here to make sure your VPS is online (Responding to ping and SSH requests). We will respond to your requests regarding the performance, network or virtualization issues within minutes. Beyond that is within your responsibility.

However, you are not left alone in the dark if you need help. We are happy to help on a courtesy basis. We are going to make sure to refer you to the right direction at all times.

If your business requires dedicated help for software assistance please consider hiring a server administrator.

If you cannot start OpenVPN on your VPS with Ubuntu 18.04, Debian 9 or CentOS 7 with the following message: "openvpn_execve: unable to fork: Resource temporarily unavailable (errno=11)"

Please do the following:

Run "sudo systemctl edit openvpn-server@" on SSH. This will open up nano editor with an empty page.

Then add the following:

[Service]
LimitNPROC=infinity

Finally, run "systemctl daemon-reload"

You do not need to clear your RAM cache. Linux has many decades of excellent memory management design built-in and will automatically free cache memory as memory pressure increases within your VPS. You can trust that Linux will release cache as necessary and won't let the system run out of memory just so it can continue to store things in cache.

The cache is a good thing and improves the performance of your VPS by using unused memory to buffer frequently-accessed files.

Clearing it will not solve any real or perceived problems. 

More info and proof of concepts available here: https://www.linuxatemyram.com/

Your Windows VPS comes with Microsoft Remote Desktop activated and ready to use.

Please follow the steps below to connect to it

Windows:

1. In the search box on the taskbar, type "Remote Desktop Connection", and then select "Remote Desktop Connection".
2. In Remote Desktop Connection, type the IP address of your VPS for "Computer" and then click "Connect".
3. When prompted enter "Administrator" for "Username" and your Administrator password for "Password".
4. Accept the certificate by clicking "Yes".

For detailed instructions with photos, please see https://vpsdime.com/knowledgebase/95_how-to-connect-to-my-windows-vps-from-another-windows-computer

Mac / MacOS / Macintosh:

1. Download and install "Microsoft Remote Desktop 10" application here: https://apps.apple.com/us/app/microsoft-remote-desktop/id1295203466?mt=12
2. Click "Add PC" button, type IP address of your VPS for "PC name" and click "Add" button.
3. Double click the added PC.
4. When prompted enter "Administrator" for "Username" and your Administrator password for "Password" and click "Continue".
5. Accept the certificate by clicking "Continue" again.

For detailed instructions with photos, please see https://vpsdime.com/knowledgebase/94_how-can-i-connect-to-my-windows-vps-from-my-mac

Android:

You can use "Remote Desktop" application for Android by Microsoft Corporation.

For detailed instructions with photos, please see https://vpsdime.com/knowledgebase/91_how-can-i-connect-my-windows-vps-using-android-phone-or-device

iPhone / iPad / iOS:

You can use "Microsoft Remote Desktop" for iOS application.

For detailed instructions with photos, please see https://vpsdime.com/knowledgebase/93_how-can-i-connect-to-my-windows-vps-using-an-iphone-or-ipad

Linux:

You can use Remmina, rdesktop or freerdp

By default, Windows virtual machines do not have sound enabled. However, there are a couple of different ways to enable sound:

Easy way:

1. Right-click on the volume icon with the red X in the system tray, then click on Sounds.
2. A dialog box will pop up asking if you want to enable the Windows audio service.
3. Click to accept, then close and re-open your Remote Desktop connection.

Sound should work without further configuration.

If the above doesn't work, you can enable the service manually:

1. Right click on the Start menu icon in the task bar, and click on Computer Management
2. Click on Services and Applications, followed by Services: https://link.cekkent.net/4ccc1068-b877-41c0-b4f7-2cef7abd6606
3. Scroll down to Windows Audio, double click on Windows Audio, and set it to start Automatic, then click the Start button: https://link.cekkent.net/aa3a2e40-af12-4537-8aa5-374d0261a5e9
4. Click OK to close the Windows Audio service box.
5. Close and re-open your Remote Desktop connection.

Sound should work without further configuration.

Two important things to keep in mind:

- After enabling sound via either method, you need to close and re-open your Remote Desktop connection for sound to work.

- Sound does not work in the console provided in the client area.