Section 5: Using NeCTAR RC

Follow

Section 5: Using NeCTAR RC

Q5.1 - How do I access the NeCTAR RC Dashboard?

The following steps should get you to your NeCTAR Dashboard.

  1. Open https://dashboard.rc.nectar.org.au/ in your web browser.
  2. When you see the Australian Access Federation (AAF) login page:
    • select your home institution (if required), and
    • click "Login"
  3. At your home institution's AAF login portal, entry your institutional login details, and click the login or sign on button.  (The details are institution specific.)
  4. If you see an AAF page asking for authorization to release some details, authorize it.
  5. If you see the AAF login page again, click login again. (It is a minor bug ... ignore it.)

You should now see the NeCTAR Dashboard.  If you've nod been there before, we recommend you take time to explore the menus.

Q5.1.1 - Why can't I see the quotas for my NeCTAR allocation?

The most likely reason is that you have the wrong NeCTAR Project selected.  In the top banner of the Dashboard at the left end, there is a pull-down project selector.  Make sure that you have your allocated project selected rather than your "PT" project.

If that doesn't help, please contact QRIScloud Support. It is possible that there has been a problem with project provisioning.

Q5.2 - What do I need to do before I start a NeCTAR Instance?

Lets assume that you have have either applied for (and been granted) a NeCTAR allocation, OR that you are using your "pt" project to launch.

If you go straight to the Dashboard and launch an instance from one of the standard NeCTAR OS images, the launch will succeed, but you won't be able to login to the new instance.  To avoid this, you need to do two things:

  • Create or upload an SSH keypair to your NeCTAR account.
  • Configure a Security Group to open the SSH port to allow you to connect from the outside.

Q5.2.1 - What is an SSH keypair?

SSH stands for "Secure Shell".  It is the protocol that you use to get a regular terminal session to your instance.

The "ssh" software supports so-called "public key authentication" as one of the ways that the computer can "authenticate" you when you login.  (In this context, the term "authenticate" means that the computer is checking that you are who you claim to be.)  Public key authentication works using key pairs, consisting of a public key and a private key.  The public key is something that you provide to other people or systems that are likely to want to authenticate you.  The private key is a secret that you keep to yourself.

The basis of public key encryption is that the public and private key are mathematically related, and it is possible for the "ssh" software to prove that you hold the private key that corresponds yo your public key.  This knowledge is deemed to be sufficient to authenticate you, just like your knowledge of your password is deemed to be sufficient to authenticate you on a conventional password-based system

The ssh configurations on a standard NeCTAR OS images are such that you must use public key authentication to login using ssh over a network connection.  (Authentication using passwords would make your system too vulnerable to hacking by repeatedly trying to guess your password.)

Q5.2.2 - What SSH client tool do I need?

You need an SSH client installed on your work computer in order to connect to a newly launched instance:

  • On Windows, the recommend SSH client is Putty.
  • On Mac and Linux, the recommended SSH client is the "ssh" command.

Q5.2.3 - How do I create an SSH keypair?

The easy way to do it (for NeCTAR) is to generate a keypair using the NeCTAR Dashboard.  Go to the "Access & Security > Key Pairs" tab, and then click "Create Key Pair".  A keypair will be generated and provided as a "pem" file that is suitable for use with the Windows "putty" command.  You can also create the SSH keypair using putty, and upload the public key to the Dashboard.

On Linux and Mac, you can generate an SSH key using the "ssh-keygen" command.

Q5.2.4 - What is a Security Group?

Network access from the outside to an OpenStack instance is controlled by a network firewall on the host that runs the instance.  A Security Group is a container for a group of access rules that let specific kinds of network from specific places through the firewall.  Each rule specifies:

  • the direction; e.g. ingress or egress
  • the network type; e.g. ethernet
  • the protocol family; e.g. TCP, UDP or UCMP
  • the port number
  • the external IP address range (in CIDR notation).

CIDR notation consists of an 4-part IP address and a netmask size e.g. "n.n.n.n/n".

  • "1.2.3.0/24" means IP addresses from "1.2.3.0" to "1.2.3.255".
  • "1.2.3.4/32" means a single IP address ("1.2.3.4")
  • "0.0.0.0/0" means all IP addresses.

See Wikipedia for more details on CIDR notation.

Q5.2.5 - How do I open the SSH port?

There is more than one way, but the simple way is to create an SSH access rule using the NeCTAR Dashboard is as follow

  1. Select the "Security & Access" panel.
  2. Select the "Security Groups" tab.
  3. Click "Create Security Group".
  4. Fill in a security group name (e.g. "SSH") and a description and click "Create".
  5. Click "Manage Rules" for the newly created group.
  6. Click "Add Rule".
  7. Select "SSH" in the Rule selector.
  8. The default CIDR is "0.0.0.0/0" ... which allows access from all IPv4 addresses.  If you want to restrict SSH access to specific places (a good idea!) then change the CIDR.
  9. Click "Add".

Remember to associate the security group with the instance when you launch it.

Note that you can change the rules in a security group after the fact.

Q5.3 - How do I start a NeCTAR Instance?

Using the NeCTAR Dashboard:

  1. Select the "Instances" panel.
  2. Click on "Launch Instance" to start the launch wizard.
  3. In the launch wizard's "Details" tab:
    • type in an instance name
    • select a flavor (see FAQ 4.1.4 for an explanation)
    • set the instance count to 1
    • set the instance boot source to "boot from image"
    • select an image (see FAQ 4.3.3 for recommendations)
  4. In the launch wizard's "Access & Security" tab:
    • make sure that your keypair is selected
    • select (at least) a security group that allows SSH access from your computer
  5. In the launch wizard's "Availability Zone" tab:
    • use the selector to choose the availability zone you want your instance to run in.
  6. Click "Launch".

The instance should launch in a couple of minutes, and the Dashboard should update as the launch procedure progresses.

If you don't select an availability zone, NeCTAR OpenStack will try to launch in the zone with the most free compute resources.

If the launch fails outright, or doesn't complete in 10 minutes, go to <page to be written> for self-help information on troubleshooting launch failures.

Q5.3.1 - How do I login to the instance?

When the instance has launched, the Dashboard will display its IP address.  To login to the instance, use the SSH client tool on your computer to connect to: "<login>@<ip-address>", where "<login>" is:

  • "ubuntu" for an Ubuntu instance
  • "debian" for a Debian instance, or
  • "ec2-user" for a CentOS or Scientific Linux instance, and old Fedora releases.
  • "fedora" for current Fedora releases.  (I think that the account name change to "fedora" happened in Fedora 21, but it is not mentioned in the release notes.)

Note that your SSH client will need to the private key corresponding to the keypair you selected when launching the instance.  If the SSH connection fails, see the SSH troubleshooting instructions (TBD).

Q5.3.2 - How do I setup my new instance?

You can now start installing application software so that you can user your instance to do useful work. However, before you start, we recommend that you do the following house-keeping:

  • Use "yum" or "apt-get" to apply the latest security updates.
  • Use "passwd" to set a password on your instance's root account.  This will allow you to login via the instance's virtual console if its SSH or network configurations are damaged.

Q5.3.3 - Is boot from volume a good idea?

Booting from a volume allows you to get around the problem that the primary file system size is limited.  (Prior to the introduction of the M2 flavours, this was a problem for applications with a large installation footprint.)  However, there are some down-sides to booting from a volume.

  • Instances booted from a volume can be problematic when you launch or terminate (due to OpenStack bugs).
  • You cannot "nova rescue" a volume that has been booted from a volume.  The rescue mechanism requires an image.
  • If you need to migrate the volume to a different volume server, "boot from volume" makes this problematic.

We recommend that "boot from volume" be avoided.

Q5.3.4 - How long can I keep an Instance running?

In theory, as long as you like.  In practice, we would prefer you to promptly terminate any instance that are not using actively, so that other users can make use of the resources.

Q5.3.5 - What should I do when I am finished?

When you are finished with an Instance, you should Terminate it.  Leaving an instance running, or in "paused" or "suspended" or "shutdown" states is tying down resources that other people could be using.

Note that terminating an instance destroys its primary and ephemeral file systems.  If you want to save the primary file system (so that you can launch a new instance), snapshot the instance before you terminate it; see FAQ 5.7.

Q5.3.6 - Can I save my instance?

The simple way to save an instance to snapshot it; see FAQ 5.7.  However, note the caveats.

Q5.3.7 - Where is my instance running?

That depends on the availability zone (AZ) that was chosen when you launched the instance. You can find this out by looking at the Instance Overview page for the instance in question

Q5.4 - How is NeCTAR usage accounted?

NeCTAR instance usage accounting records the following things:

  • The number of VCPU-hours used.  This is the number of VCPUs used multiplied by the time that the instance is live, integrated over all instances launched in a project.
  • The number of GB-hours used. This is the number of GB of memory used multiplied by the time that the instance is live, integrated over all instances launched in a project.

In both cases, the lifetime starts when the instance is launched and ends when it is terminated.  An instance that is in shutdown, paused or suspended states still counts as "live".

Q5.5 - How do I use Volume Storage?

A previous FAQ explained what Volume Storage it.

There are 5 steps involved in using a Volume in a Project to provide file storage for an Instance in the project:

  1. Create the Volume
  2. Attach the Volume to an Instance
  3. Format the Volume
  4. Mount the Volume
  5. Set up the Volume to mount on reboot.

Note that NeCTAR Volume Storage has the following technical limitations:

  • Volume storage quotas are (now) allocated within individual AZ's, not federation-wide.
  • A Volume cannot be attached to an Instance in a different AZ.
  • A Volume cannot be shared with another Project.
  • A Volume cannot be attached to two (or more) running Instances simultaneously.

Q5.5.1 - How do I create a Volume?

Using the NeCTAR Dashboard:

  1. Select the "Volumes" tab in the "Volumes" panel.
  2. Click "Create Volume"
  3. Fill in the following fields:
    • A volume name
    • A volume description
    • Select "no source, empty volume" as the source
    • Set the requested volume size in Gigabytes.
    • Select the Availability Zone.
  4. Click "Create Volume".

Q5.5.2 - How do I attach a Volume to an Instance?

Using the NeCTAR Dashboard:

  1. Select the "Volumes" tab in the "Volumes" panel.
  2. Pull down and select the "Edit Attachments" action for the Volume that you want to attach.
  3. In the "Manage Volume Attachments" dialog, select the Instance from the pulldown.
  4. Click "Attach Volume".

The Volume will be attached to the instance as the next available virtual disc device.  This will typically be "vdc", since "vda" and "vdb" are normally bound to the instance's primary and ephemeral file systems.

There are many ways to identify the disk device files for an instance.  A simple one is to run the following:

   $ lsblk -io KNAME,TYPE,SIZE,MODEL

and look for entries that correlate to the size of your volume. The device files are all in the "/dev" directory, so the device pathname for "vdc" is "/dev/vdc".

Q5.5.3 - How do I format a Volume?

WARNING: Formatting a volume will destroy any existing files (if any) on the volume.  You should only do this for a newly created volume, or if you are really sure that reformatting is the right thing to do.

WARNING: If you format the wrong device, you will destroy the files on that file system.

Before you create a file system you need to know, and be sure of, the following:

  • The device pathname for the attached volume.  See previous FAQ.
  • The type of file system you want to create.  We recommend that you use "ext4" which is a modern "journalling" file system, but there are a variety of other file system types.

The command to format a volume with a single file system is:

   $ sudo mkfs.<type> <device-path>

 or

   $ sudo mkfs -t <type> <device-path>

where the <type> and <device-path> are as above.  If you are worried about trashing existing data (and you should be!) then you can run the following first to "dry run" the command.  This will run the command without changing anything on disk.

   $ sudo mkfs -V -V -t <type> <device-path>

For more information on file systems and the "mkfs" command(s):

(It is also possible to partition a volume and format it with multiple filesystems, but that is beyond the scope of this FAQ.)

Q5.5.4 - How do I mount a Volume?

Assuming that your volume has previously been formatted (as a single file system), you can mount it as follows:

   $ sudo mkdir /myvolume
   $ sudo mount <device-path> /myvolume

where <device-pathname> is the device pathname as above, and "/myvolume" is the mount point for the volume file system. When the volume has been mounted, the mount point will be the top-level directory for the mounted file system.

Notes:

  1. The "/myvolume" can be any directory.  It doesn't need to be in the "/" directory, and it doesn't need to be empty. 
  2. If you mount a volume on a non-empty directory, the mount directory's contents will be hidden until the the volume is unmounted.
  3. Mounts only last until the instance is shutdown (but see below).

Q5.5.5 - How do I setup a Volume to mount on reboot?

The simple way to do it is to edit the "/etc/fstab" file to add a line like this:

  /dev/vdc    /myvolume  ext4   defaults   0 2

changing the device pathname, the mount point and the file system type as required.  (It is also possible to use an automounter, but this is not recommended for a simple use-case.)

Advice: if you detach and reattach a volume, check the device name doesn't change.  If it does, update the "/etc/fstab" file.

For more information on mounting:

Q5.5.6 - Can I get around the Volume / Project / Instance limitation?

Not directly.  However, if you are prepared to put in some effort you could attach a Volume to one Instance, and then configure the Instance as a private NFS server that your other Instances can access.

Note that there are various security-related issues that need to be understood and addressed if you go down this path.

Q5.6 - How do I use Object Storage?

There are many ways to use Object Storage:

  • You can manage an object storage container, and upload and download objects using the Dashboard.
  • You can do the same from the command line.
  • You can do the same from a variety of programming languages.
  • Some third-party applications and tools can access Object Storage.

The other thing to note is that other kinds of NeCTAR storage, NeCTAR Object Storage can be accessed from any computer that HTTPS access to the public internet.

Q5.6.1 - What is an Object Storage Container?

A Container is a logical place to put Object Storage objects.  Each NeCTAR Project can have multiple containers, and each container can contain multiple objects.

Q5.6.2 - How do I create a Container?

Using the NeCTAR Dashboard:

  1. Select the "Object Store > Containers" panel.
  2. Click "Create Container".
  3. Fill in the "Container name".  (Container names cannot contain a "/" character.)
  4. Select "Container access" of either "public" or "private".
  5. Click "Create container".

The newly created Container should be displayed in the Dashboard.

Q5.6.3 - What is an Object?

An Object is data held as a "sequence of bytes". An Object has associated metadata including a name, content type, content encoding, checksum and timestamps.

Q5.6.4 - How do I create an Object?

 Using the NeCTAR Dashboard:

  1. Select the "Object Store > Containers" panel.
  2. Click on the Container link for the container where you want the Object to be created.
  3. Click on the "Upload Object" button.
  4. Use the "Browse" button to select a file on your local computer to upload.
  5. Enter an object name.
  6. Click "Upload".

The Container's shows the all of the your containers, and the objects in the currently selected selected Container.  Unfortunately, there are no obvious visual cues to tell you which container is selected.

Q5.6.5 - How do I retrieve an Object?

 Using the NeCTAR Dashboard:

  1. Select the "Object Store > Containers" panel.
  2. Click on a Container link to select the right container.
  3. Find the object that you want to retrieve and click "Download".
  4. Tell your browser to save the file.

Q5.6.6 - What is a Pseudo-folder?

Object Storage Containers don't behave like convention file system folders or directories. Instead, OpenStack allows you to use the slash ("/") character to add structure to Object names to create what are know as pseudo-folders. The "Object Store > Containers" panel allows you to select a pseudo-folder so that only Objects that it contains are displayed.

Q5.6.7 - How do I delete Objects, Pseudo-folders & Containers?

You can do these things using the NeCTAR Dashboard.  The caveat is that you have to delete things in the right order. You cannot delete a container or pseudo-folder until it is empty.

Q5.6.8 - Can I rename Objects?

No.  Rename functionality is not supported by the Swift APIs.  However, there is functionality for copying Objects within and between containers (owned by the same project)

Q5.6.9 - How do I use Object Storage from the command line?

  • You can use the standard "curl" or "wget" tools to send GET / PUT / POST / DELETE etcetera requests to the Swift API.
  • You can install, configure and use the OpenStack "swift" command-line client.

Q5.6.10 - How do I use Object Storage from a program?

  • You can use a Swift client library.
  • You can use a (lower level) HTTP client library.

For more information:

Q5.6.11 - Is use of OpenStack's S3 compatibility APIs advisable?

There is no technical reason not to do this.  OpenStack's Amazon S3 compatibility APIs are reliable, albeit that the documentation is pretty "sketchy".

Q5.7 - What is a Snapshot?

A snapshot is (roughly speaking) a disk-block level copy of a file system.

An Instance snapshot is a copy of the primary file system of an Instance.  Instance snapshots are Images (see above) and are held in the OpenStack image service (Glance. You can see them initially in the "Project Images" tab in the "Images" panel.

A Volume snapshot is a copy of a Volume.  Volume snapshots are held in the OpenStack volume service (Cinder). You can see them in the "Volume Snapshots" tab in the "Volumes" panel.

Q5.7.1 - Are there caveats on Snapshots?

There are a couple of caveats:

  • Instance snapshots do NOT include the ephemeral file system, or the state of any attached volumes.  (Volumes may be snapshotted separately though.)
  • Some people have experienced problems launching snapshots created in a different data AZ due to hardware or networking compatibility issues.

Q5.7.2 - How do I create a Snapshot?

Snapshots can be created via the NeCTAR Dashboard:

  • Creating an Instance snapshot is an "action" you can perform via the Instances panel.
  • Creating a Volume snapshot is an "action" you can perform via the Volumes panel.

Under normal circumstances, creating an Instance snapshot should only take a few minutes.  If a snapshot gets "stuck":

  1. Delete it and try again.
  2. Try shutting down your instance first.
  3. If neither of those workarounds work, raise a QRIScloud support request.

There is a Virtual Wranglers article on Troubleshooting Instance Snapshots.

Q5.7.3 - Do I need to shut down before creating a Snapshot?

In theory, no.  In theory, a snapshot should the state of the instance at a particular instant in time, and this can include the memory state of the instance if it is running.  In practice:

  • Instance snapshots on NeCTAR don't include ephemeral file systems, or attached volumes.
  • You cannot "resume" a NeCTAR instance snapshot. Instead you launch a new instance, and that new instance won't be able to use any saved memory state.

Therefore, we strongly recommend that you shut down your instances before snapshotting.

You will get the most reliable snapshots if you take them while the system is "quiesced", and shutting down the instance is the only reliable way to do that on NeCTAR OpenStack.  If you take snapshot of an active system, you can run into the following problems:

  • If you catch the system at the wrong instant, file system updates may be in the journal, but not the main file system. This will require a manual file system check ("fsck") to recover.
  • If an application (or database) was active, it could have been in the middle of updating an important file. Depending on how resilient the application is to unplanned interruptions, this could lead to data loss.

Taking snapshots of running systems is also more likely to run into operational issues as described in the Troubleshooting Instance Snapshots article.

Q5.8 - How do I manage my Project?

Most OpenStack-level operational tasks can be performed through the NeCTAR Dashboard.

  • A project manager can add and remove project members (provided that they previously visited the NeCTAR RC Dashboard.
  • A project manager or member can manage instances, volumes, objects, images and security groups.
  • A project manager can apply for an increase (or decrease) in resources by amending the allocation request.
  • A project member can manage the instances, volumes, objects and images associated with a project.

The only significant management tasks that cannot be done using the Dashboard are adding, removing or changing a project's Tenant Manager, and shutting down a project.  These tasks require a QRIScloud (or NeCTAR RC) support request.

Q5.8.1 - How do I delegate management of my Project?

If you make someone a Member (FAQ 5.8.2) or a Tenant Manager (FAQ 5.8.3) of your project, they will be able to perform operational tasks for the resources in the project.  They will also need SSH keypairs for a privileged account on the instances to perform various tasks.

That is the easy part. The harder part (especially for a non-technical project director) is ensuring that the person you have delegated responsibility to has the appropriate skills and experience, and is aware of the things that they need to do to keep your system running. The following Virtual Wranglers articles may be helpful to help you understand.

Q5.8.2 - How do I add or remove a Member of my Project?

You (or any Tenant Manager for the project) can add and remove project members using the NeCTAR Dashboard:

  1. Select the Project.
  2. Select the "Users > Users" panel.
  3. To add a member:
    • Click the "Add.."
    • Copy and paste the user's AAF identifier into the field.
    • Click the submit button.
  4. To remove an existing member, use the "Remove User" action next to the user's entry.

Notes:

  • The AAF identifier is the email address-like string that the user sees at the top right of their NeCTAR Dashboard. Note that you cannot use any old email address.  You have to use the one that AAF uses as the canonical email for the user.
  • You cannot remove yourself from a project.

Q5.8.3 - How do I add or remove a Tenant Manager for my Project

To do this, you need top submit a NeCTAR Support Request.  State clearly who you want added or removed. If you are not currently a Tenant Manager for the project, the NeCTAR Support staff will ask for authorization from a current Tenant Manager.

Q5.9 - Is it a good idea to use the AWS EC2 compatibility APIs?

This is a complicated question, but at this point in time we recommend that you don't do it.  The issues are summarized by this Virtual Wranglers "NeCTAR Topics" article:

Q5.10 - What about Security?

Security of your NeCTAR instances is your responsibility.

  • The NeCTAR Terms of Use state clearly that instance security and backup are the users' responsibility.
  • The NeCTAR Support site has a Security Guidelines page with lots of advice on how to keep your NeCTAR resources secure.

If we (QRIScloud or NeCTAR) see evidence that an instance's security has been comprised, we will take immediate steps to shut it down, and isolate it so that it cannot do any further damage to NeCTAR reputation and infrastructure or to other NeCTAR users' assets.  See FAQ 5.10.5 below for more details.

Note that compromised (hacked) NeCTAR instances are a real issue. Across the NeCTAR federation, we see examples on a regular basis. The consequences of your system being hacked can be severe, including:

  • disruption to your work because your hacked instance has been taken offline,
  • significant extra work for you and your in-house support staff to rebuild the instances, or
  • permanent loss of data if you did not have adequate backup procedures in place.

 As the Terms of Use indicate, NeCTAR has the discretion to ban people or groups whose instances are repeatedly hacked.

Q5.10.1 - How do I apply system patches?

For CentOS, Scientific Linux and Fedora systems and others that use the "yum" package manager:

$ # to apply all updates
$ sudo yum update

$ # to apply only security updates
$ yum -y install yum-plugin-security

For Ubuntu and Debian systems, and others that use the "apt" package manager:

$ # to apply all updates
$ sudo apt-get upgrade

$ # to apply only security updates
$ apt-get -s dist-upgrade | grep "^Inst" | grep -i securi | \
awk -F " " {'print $2'} | xargs apt-get install

Q5.10.2 - When should I apply system patches?

If you are applying patches by hand, we recommend that you do it at least once a week.

Alternatively, it is easy to configure a recent Linux system to apply patches automatically:

The "yum" instructions also discuss the pros and cons applying patches automatically, and some alternatives.

Finally, we recommend that you apply all patches, not just security patches.

Q5.10.3 - What to do when system patches are discontinued?

If system patches are discontinued, you should update to a more recent version of the operating system.  You should treat this as a matter of urgency.

Q5.10.4 - How do I configure the firewall?

NeCTAR instances have public IP addresses, and are on the open internet. There are lots of people out there who are continually probing for new systems that they may be able to hack into. One of the things you need to do to protect yourself against this is to

The easy way to configure your instance's firewalling it is to use Security Groups (see above). You can also configure additional firewalling inside your virtual machine.  (You might do this if you were worried about the external firewalling not working.)

Q5.10.5 - What happens if my NeCTAR instance gets hacked?

The standard NeCTAR-wide procedure for dealing with a hacked instance is:

  1. Immediately suspend the instance and lock it to stop you from restarting it.
  2. Notify you that the instance has been compromised, and suspended.
  3. Provide you with a link for downloading the primary image and (if requested) the ephemeral disc.
  4. 7 days later, Terminate the instance.

Under no circumstances will we remove the lock to allow you to restart the instance. Once an instance has been compromised, there is no way to guarantee that the hackers have not installed hidden back-doors to get back into the system. The only safe option is to build a new instance from a clean image, and make sure that the security holes that allowed the compromise have been closed.

We generally don't have the resources to help you definitively determine how your instance was hacked.

Q5.10.6 - My NeCTAR instance is being probed by another NeCTAR instance.  What do I do?

It is common for NeCTAR instances to be probed by hackers from around the world, and there is little that we can do about it. However, if you notice that your instance is being probed by another instance, please report it to QRIScloud Support.

However, note that it could be a "false alarm".  For instance, in QRIScloud, we have set up a Nessus security scanner that probes all QRIScloud instances regularly looking for vulnerabilities.  So if you see probes coming from "sec.qriscloud.net.au" (currently 203.101.225.21), this is not an attack.

Q5.11 - What about backup?

Backup of your NeCTAR instances and data stored on NeCTAR storage is entirely your responsibility.  We advise that you implement regular automated backups, monitor that they are working, store backups in a safe place, and implement and test your own disaster recovery procedures.

We regularly hear about users who have neglected to implement backups, or implemented a scheme that is manifestly inadequate. Typically, the first we hear is when users are already in trouble.  Sometimes we can help.  Often we can't, and the user's data is lost for ever.

Q5.11.1 - How do I implement backups?

There is a Virtual Wranglers page on the topic implementing backups for NeCTAR virtual machines.  There is no "one size fits all" recommendation.

Q5.11.2 - How to I know my backups are adequate?

The best way to be sure is to test them.

  • Pretend that you have lost some files and try to recover them from the backups.
  • Pretend that you have lost an entire instance, and try to reconstruct a fresh instance from the backups.
  • Pretend that you have lost your on-site backup as well. and try to restore from your off-site copy (if you have one).

Q5.11.3 - Are Snapshots a good way to implement backups?

On the one hand, snapshots are a simple way to record a previous state of a system. On the other hand, they are a cumbersome and inefficient way to implement backups.  For example:

  • Each snapshot is a copy of everything, and that takes a lot of storage.  By contrast, a typical backup system records a complete copy of the file system state, and a sequence of incremental snapshots that represent only the files that have changed.
  • Instance and Volume snapshots are kept on disc.  In the case of Volume snapshots, they will be on the same storage cluster as the Volume that you are backing up.
  • Finding and selectively retrieving old files from snapshots is labour intensive, especially in the case of Instance snapshots.
Have more questions? Submit a request

Comments

Powered by Zendesk