Cloudant のような NoSQL データベースの場合、バックアップは一般的には複製機能によって実現するケースが多いのかもしれません。要は生きたデータベースを２系統以上用意して、生きたデータベースにバックアップする、という考え方です。これだとメインDBに障害があってもすぐに切り替えて稼働ができます。
ただ、例えばデータベースの引越しが目的の場合や、あるタイミングでのスナップショットを取るような場合などでは、一旦データベースのダンプを取得して、引越先でリストアしたい、というケースもあります。このようなケースでは生きたデータベースに複製することが必ずしも正しい回答にはなりません。
そういった場合のダンプは以下のコマンドで取得することができます：
上記例では file.dump というファイル名を指定してダンプ結果を取得するように指示しています。ダンプというか、データベースの _all_docs（全ドキュメント） に include_docs_true（中身ごと取得）オプションを付けて GET する、というよく考えたらごく普通のコマンドをそのまま実行しています。
取得したダンプファイル（file.dump）を使ってリストアする場合はちょっと準備が必要です。まず上記コマンドで取得したダンプファイルをテキストエディタで開き、１行目の "rows" を "docs" に書き換えて保存します：
編集後に次のコマンドを実行します：
こちらはデータベースに対して、中身を JSON ファイルで指定して POST しているだけです。
これで手動でバックアップができるので、後はこれを cron などで自動化したり、取得したダンプファイルを外部のオブジェクトストレージとかに転送する仕組みまで作ってしまえば自動バックアップが実現できそうです。
（2016/Jul/30 追記）
上記方法でもリストアできますが、元のデータベース内と比べて JSON ドキュメントのフォーマットが変わってしまいます。フォーマットを変えずにリストアする場合の方法は別のエントリで紹介しています：
Cloudant のバックアップデータをリストアする
ただ、例えばデータベースの引越しが目的の場合や、あるタイミングでのスナップショットを取るような場合などでは、一旦データベースのダンプを取得して、引越先でリストアしたい、というケースもあります。このようなケースでは生きたデータベースに複製することが必ずしも正しい回答にはなりません。
そういった場合のダンプは以下のコマンドで取得することができます：
$ curl -X GET https://(username):(password)@(hostname)/(dbname)/_all_docs?include_docs=true > file.dump
上記例では file.dump というファイル名を指定してダンプ結果を取得するように指示しています。ダンプというか、データベースの _all_docs（全ドキュメント） に include_docs_true（中身ごと取得）オプションを付けて GET する、というよく考えたらごく普通のコマンドをそのまま実行しています。
取得したダンプファイル（file.dump）を使ってリストアする場合はちょっと準備が必要です。まず上記コマンドで取得したダンプファイルをテキストエディタで開き、１行目の "rows" を "docs" に書き換えて保存します：
{"total_rows":100,"offset":0,"rows":[
:
:
↓ "rows" を "docs" に書き換えて保存
{"total_rows":100,"offset":0,"docs":[
:
:編集後に次のコマンドを実行します：
$ curl -d @file.dump -H "Content-Type: application/json" -X POST https://(username):(password)@(hostname)/(dbname)/_bulk_docs
こちらはデータベースに対して、中身を JSON ファイルで指定して POST しているだけです。
これで手動でバックアップができるので、後はこれを cron などで自動化したり、取得したダンプファイルを外部のオブジェクトストレージとかに転送する仕組みまで作ってしまえば自動バックアップが実現できそうです。
（2016/Jul/30 追記）
上記方法でもリストアできますが、元のデータベース内と比べて JSON ドキュメントのフォーマットが変わってしまいます。フォーマットを変えずにリストアする場合の方法は別のエントリで紹介しています：
Cloudant のバックアップデータをリストアする
