Tag

backups Archives - AWS Managed Services by Anchor

Out-Tridging Tridge

By | Technical | 2 Comments

Andrew Tridgell’s rsync utility is widely used for pushing files around between servers. Anyone can copy files across the network, what makes rsync special is that it compares the files on each end and only transfers the differences, instead of pushing the whole file across the wire when only a few bytes need to be updated. We use rsync to backup servers every single day, though we recently found a few big files where rsync was going to take an eternity to perform what should’ve been several hours of work. So, we busted out the butterfly nets and went to catch us some bugs. rsync in a nutshell Most servers don’t change a great deal on a day to day basis, so transferring just the differences is a very smart…

Read More

The btrfs backup experiment

By | Technical | 4 Comments

Today we’re talking about our experience with btrfs, the next-gen Linux filesystem. btrfs has been maturing rapidly over the last few years and offers many compelling features for modern systems, so we’ve been putting it through its paces on some of our backup servers. How does it stack up? Read on! We chose to test btrfs on backup servers because they can make good use of the features on offer, and the threat-level of data loss is low. For our backups, the biggest benefit comes from copy-on-write and atomic snapshots. At Anchor we use a modified version of Dirvish with support for btrfs: instead of hardlinking directories to provide historical snapshots we just use btrfs’ snapshot facility, which is very quick. Expiring old snapshots is similarly quick – it’s a…

Read More

Extending Redis to scratch an itch

By | Technical | No Comments

Redis has become one of the most popular “noSQL” datastores in recent times, and for good reason. Customers love it because it’s fast and fills a niche, and we love it because it’s well behaved and easy to manage. In case you’re not familiar with Redis, it’s a key-value datastore (not a database in the classic sense). The entire dataset is always kept in memory, so it’s stupendously fast. Durability (saving the data to disk) is optional. Data in Redis is minimally structured; there’s a small set of data types, but there’s no schema as in a traditional relational database. Thanks to some peculiarities in the way Redis is implemented, it can offer atomic transactions that are difficult to achieve in normal database products. That’s not to say it’s perfect…

Read More

A little news on backups and why they matter

By | Company News, Technical | No Comments

One of our sysadmins has been cleaning up and auditing our backups recently, and we thought we’d look at some of the numbers involved and how they’ve changed over time. Several years ago we used tapes exclusively, and they were always taken offsite. We don’t have the numbers from that time, but every fully-managed server came with backups included. AMANDA is still our backup software of choice and it’s been a reliable system for many years. That said, tapes aren’t really a good match for many of our customers’ needs, and the costs can be prohibitive. That’s why we developed our onsite disk-based backup solution. As well as being able to offer large amounts of storage at a much lower cost to the customer, the experience is actually better because…

Read More

Backups for Postgres that don’t suck

By | Technical | No Comments

PostgreSQL is awesome in many, many ways. One of these ways is in its use of a write-ahead log, or WAL, that enables: Atomicity Durability Replication (that isn’t insane, like MySQL’s) Backups And much much more! </televisionSalesman> We’re interested in backups today, because textual dumps for backups (the lowest common denominator for mysql and pgsql) puts a lot of load on the server and tends to be very slow. We started looking into something like mylvmbackup for postgres, but then discovered that there was no need – it’s already built in! We’ve made a easy guide to trying it out for yourself. It’s fairly detailed and hands-on, so we’ve split things out to a separate page: Better PostgreSQL backups with WAL archiving If you’re a Postgres user, we’d love to…

Read More

Implementing proper trust relationships in backup systems

By | Technical | No Comments

As many people may have read today, a certain web hosting company which operates in Australia suffered an attack which resulted in significant amounts of data loss. Not only was their live production data lost, but all backups were also unrecoverably lost in the process. Whilst significant technical details have yet to be released as to the nature of these attacks, now is an opportunity as good as ever to explain how the trust relationships exist between the backup server and the system being backed up across our entire server infrastructure. Our backup servers are separated with there being a minimal trust relationship between the backup server and the system being backed up: All backups happen on an independent network which is inaccessible from the Internet. The backup server can…

Read More

Envy our new Leviathan!

By | Technical | One Comment

Our current rdiff and amanda backup server, KRAKEN, is almost full, so it was time to order a new one. After much wrangling, we finally received LEVIATHAN this morning. I was pushing for PHYREXIAN DREADNOUGHT personally, but LEVIATHAN is acceptable too; the upkeep effort of backup servers is pretty high after all.

Read More

News flash: widespread power outage hits Sydney CBD, Anchor hosting operations unaffected

By | Company News, Technical | No Comments

Sydney suffered a nasty power outage in the CBD on Monday, which according to reports affected tens of thousands of homes and businesses. Curiously, some traffic lights on George street were blacked out while others just a block or two away were working fine. From a technical standpoint, a measure of diversity like that is probably a good thing. Rather than having vast areas with unmanaged traffic flow, police could be deployed where necessary, with the knowledge that vehicles could move a meaningful distance before getting stopped at the next set of blacked-out lights. A friend of one staffer at Anchor was expected to be staying back late last night babysitting the systems in their office that would take some time to come online. Meanwhile over at Anchor’s datacentre, things…

Read More