# Asrestore to the other side of the planet.. some observations

**URL:** <https://discuss.aerospike.com/t/asrestore-to-the-other-side-of-the-planet-some-observations/9592>\
**Category:** Operations\
**Created:** [July 14, 2022, 2:27pm UTC](https://discuss.aerospike.com/t/asrestore-to-the-other-side-of-the-planet-some-observations/9592 "2022-07-14T14:27:29Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jeff.MacDonald](https://avatars.discourse-cdn.com/v4/letter/j/e9bcb4/32.png) [@Jeff.MacDonald](https://discuss.aerospike.com/u/Jeff.MacDonald)\
**Post date:** [July 14, 2022, 2:27pm UTC](https://discuss.aerospike.com/t/asrestore-to-the-other-side-of-the-planet-some-observations/9592/1 "2022-07-14T14:27:29Z")

</div>

Hi. I’m curious about the nature of `asrestore` over high latency (long distances).

I am restoring a 500gb namespace to a cluster. I tried 2 ways

1. Backup to a server in Toronto, and run asrestore over the network to a server in Tokyo.
2. Copy the backup from Toronto to Tokyo and run asrestore entirely in Tokyo.

In scenario #1: I was comparing/restoring about 130 records per second. In scenario 2 it’s about 90,000 per second. ETA in Scenario one was always more than 100 days. Scenario 2, about 9 ish hours. +/-

I’m curious about the mechanisms in play here? Is there a lot of back and forth between asrestore and the cluster that accounts for this large of a discrepancy?

Also related/not related , is `asbackup | asrestore` a pattern that is ever employed to easily seed a cluster ?

---

<div class="post-metadata">

**Author:** ![Albot](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/albot/32/2076_2.png) [@Albot](https://discuss.aerospike.com/u/Albot)\
**Post date:** [July 15, 2022, 6:30am UTC](https://discuss.aerospike.com/t/asrestore-to-the-other-side-of-the-planet-some-observations/9592/2 "2022-07-15T06:30:13Z")

</div>

That’s because it restores the records 1-by-1 so there is a lot of chatter/await. You’d probably get similar better results streaming over the internet with more threads, but I like being able to transfer the file and do a md5sum for a warm fuzzy feeling. For piping commands together, I’m a fan of `asbackup -o - | pzstd -1 | cat | nc <remote details>` and on a single node on the remote side you can `nc listen | cat | pzstd -d| asrestore -i -` or even on multiple nodes if you want to make it complicated (multiple asbackup/asrestore sites and each doing different series of partitions). The commands I pasted are probably not 100% complete, but thats the jist of it mostly. Netcat to create the tcp tunnel and then use some compression before sending it over the wire. I think Aerospike may have even added a compress option to their tools but can’t recall… may be worth looking into.

---

<div class="post-metadata">

**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/system/32/2274_2.png) [@system](https://discuss.aerospike.com/u/system)\
**Post date:** [July 15, 2023, 6:30am UTC](https://discuss.aerospike.com/t/asrestore-to-the-other-side-of-the-planet-some-observations/9592/3 "2023-07-15T06:30:50Z")

</div>

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.