# Efficient ways to clone a canister’s data **URL:** \ **Category:** Developers\ **Created:** [April 11, 2022, 2:33pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066 "2022-04-11T14:33:28Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [April 11, 2022, 2:33pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/1 "2022-04-11T14:33:28Z")
I’m looking into solutions that would allow me to build an auto-scaling solution for canisters based on the current memory utilization of the canister, and part of this solution involves being able to fully clone or partially replicate the data stored in the canister and then to repartition the data amongst the original canister and clone(s). The only (and most expensive option) I can think of right now is to use inter-canister update calls, but when we’re talking about 1-2 GB of data this would be a somewhat slow process based on what I’ve seen from others. I could also maintain multiple canisters from the start, but this is then 2X the cost. Is there any way to pull out a canister replica for this purpose via a clone() type of functionality? If not, are there any other current solutions or ongoing work/roadmap items that might help IC Devs clone or repartition the data in canisters? ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [April 11, 2022, 4:00pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/2 "2022-04-11T16:00:56Z")
Also see discussion here: [Canister backup - #19 by skilesare](https://forum.dfinity.org/t/canister-backup/11777/19) This would be great. I know that there is work underway for downloading the current wasm state, but it would also be great if the replica could just copy it and start running it under a different canister id. ---
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [April 11, 2022, 9:23pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/3 "2022-04-11T21:23:58Z")
Thanks for linking that discussion. > [@Canister backup](https://forum.dfinity.org/t/canister-backup/11777/19): > > It is much easier to copy a canister and delete the first half of the data on the first and the second half on the other than to do 4GB/2MB= 2000 intercanister calls to move data from one to another. This clone/copy and delete methodology is exactly my thinking. Fully copying a canister through inter-canister calls is both expensive and would take a significant amount of time, not to mention you now introduce a whole bunch of distributed systems problems with what to do if a 1-2GB canister data copy fails in the middle (since you would be splitting the copy process into multiple update calls supposedly). > [@Canister backup](https://forum.dfinity.org/t/canister-backup/11777/18): > > Why don’t you just use another canister for the backup? While this works great for backups, you have to start out by spinning up that extra canister before. This doesn’t work if you’re auto scaling out in a reactionary fashion, and to top it off doesn’t effectively tackle the problem of if you have data that is unevenly distributed (based on a particular primary key). The intermediate solution that a few teams have come up with is to find a specific entity that they do not believe will push the 4GB canister limit anytime soon (say a user, or a message chat on OpenChat) and just spin up a new canister for each of those entities. I think that the above will most likely be my approach (in the intermediate term), as I’m certain that a deeper IC based solution (either the replica copy solution or another solution) is the way to go in the long term. Building off of this, I’m assuming these clones would then be bounded by the individual subnet of a particular application - which would then be the next bottleneck. @diegop From a brief glance I didn’t see this on the [2022 Sneak Preview RoadMap](https://forum.dfinity.org/t/ic-roadmap-milestones-for-2022-sneak-preview/10527). Are there any Roadmap items that might tackle this problem or engineers that might be able to comment on the feasibility/work required to perform efficient canister data cloning? ---
**Author:** ![jzxchiang](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jzxchiang/32/2592_2.png) [@jzxchiang](https://forum.dfinity.org/u/jzxchiang)\ **Post date:** [April 12, 2022, 1:31am UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/4 "2022-04-12T01:31:36Z")
+1, this would be very useful. Even a feature that lets canister owners download/upload a canister’s state would essentially allow us to clone a canister. Last I checked it was on the roadmap, but I don’t know the current status. @akhilesh.singhania, do you happen to know? Thanks! ---
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [May 30, 2022, 11:32pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/5 "2022-05-30T23:32:27Z")
From [How would Internet Identity handle a denial of service attack? - #10 by faraz.shaikh](https://forum.dfinity.org/t/how-would-internet-identity-handle-a-denial-of-service-attack/12791/10) > [@How would Internet Identity handle a denial of service attack?](https://forum.dfinity.org/t/how-would-internet-identity-handle-a-denial-of-service-attack/12791/10): > > Consensus: The P2P layer implements fixed-sized i/o queues per replica. So malicious replicas cannot overwhelm other replicas. These queues are sized (size and count of messages) sufficiently well such that replicas operating within the protocol limits will never run out of queue space. I a replica genuinely falls behind (transient sluggish network) it can ask for retransmission to do a quick resync. **If a part of the subnet is lagging behind for longer periods of time - it will fail to do quick resyncs and eventually fall back to CUP-based state-syncs. This queuing model works on the premise the CUP-based state syncs are orders of magnitude faster than actual consensus-based progress.** This got me looking into CUPs, or catch-up packages, which are very briefly described in section 8.2 of [The DFINITY Foundation](https://dfinity.org/whitepaper.pdf). From the whitepaper, section 8.2. > A CUP is a special message (not on the blockchain) that has (mostly) everything a > replica needs to begin working in a given epoch, without knowing anything about previous > epochs. It consists of the following data fields: > > • The root of a Merkle hash tree for the entire replicated state (as opposed to the > partial, per-round certified state as in Section 6.1). > • The summary block for the epoch. > • The random beacon for the first round of the epoch. > • A signature on the above fields under the (n − f )-out-of-n threshold signing key for > the subnet. > > To generate a CUP for a given epoch, a replica must wait until the summary block > for that epoch is finalized and the corresponding per-round state is certified. As already > mentioned, the entire replicated state must be hashed as a Merkle tree — even though a > number of techniques are used to accelerate this process, this is still quite expensive, which > is why it is only done once per epoch. Since a CUP contains only the root of this Merkle > tree, a special state sync subprotocol is used that allows a replica to pull any state that it > needs from its peers — again, a number of techniques are used to accelerate this process, > but it is still quite expensive. Since we are using a high-threshold signature for a CUP, we > can be sure that there is only one valid CUP in any epoch, and moreover, there will be > many peers from which the state may be pulled. Also, since the public key of the threshold > signature scheme remains constant over time, the CUP can be validated without knowing > the current participants of the subnet @faraz.shaikh The section describes how “expensive” a CUP sync is, but are there any performance tests on how long it takes to CUP sync catch up something like 1GB of canister state? The reason why I ask is I’m wondering if CUP syncs could be used for cloning or forking of a canister at a given point of time (spinning up a new, but distinct canister from a CUP sync). ---
**Author:** ![patnorris](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/patnorris/32/11764_2.png) [@patnorris](https://forum.dfinity.org/u/patnorris)\ **Post date:** [February 10, 2025, 3:23pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/6 "2025-02-10T15:23:01Z")
Hi there, we’d also love to clone canisters for an application we’re working on and I wondered if there are any updates on this. I looked into the canister snapshot functionality but as far as I understand it cannot be used for cloning. Have you found any solution to achieve cloning canisters that you could share? ---
**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\ **Post date:** [February 10, 2025, 3:24pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/7 "2025-02-10T15:24:03Z")
The ability to download and re-upload a snapshot to a canister is in the works right now ---
**Author:** ![patnorris](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/patnorris/32/11764_2.png) [@patnorris](https://forum.dfinity.org/u/patnorris)\ **Post date:** [February 11, 2025, 8:22am UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/8 "2025-02-11T08:22:54Z")
cool, thanks for sharing the info 👍 ---
**Author:** ![apotheosis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/apotheosis/32/24516_2.png) [@apotheosis](https://forum.dfinity.org/u/apotheosis)\ **Post date:** [July 31, 2025, 1:30pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/9 "2025-07-31T13:30:05Z")
Did this ever get done? We want to copy data from one canister into a new one. ---
**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\ **Post date:** [July 31, 2025, 1:47pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/10 "2025-07-31T13:47:18Z")
It’s still in progress. Cloning data is just one small step in the bigger feature of migrating a canister across subnets. I’ll see if someone can give some estimates… ---
**Author:** ![michael-weigelt](https://avatars.discourse-cdn.com/v4/letter/m/b487fb/32.png) [@michael-weigelt](https://forum.dfinity.org/u/michael-weigelt)\ **Post date:** [July 31, 2025, 1:58pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/11 "2025-07-31T13:58:19Z")
Hi, you can expect this feature to be released in the coming weeks. ---
**Author:** ![Gabriel](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gabriel/32/546_2.png) [@Gabriel](https://forum.dfinity.org/u/Gabriel)\ **Post date:** [July 31, 2025, 3:08pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/12 "2025-07-31T15:08:03Z")
Can you elaborate on what is going to be released? like a full scale clone functionality? Is the download/upload based on http? ---
**Author:** ![apotheosis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/apotheosis/32/24516_2.png) [@apotheosis](https://forum.dfinity.org/u/apotheosis)\ **Post date:** [July 31, 2025, 5:49pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/13 "2025-07-31T17:49:26Z")
The use-case here for [kinic.io](http://kinic.io) We have users who make their AI memory canisters. We want them to be able lend those out for a fee. People often ask me ”What should I do in Tokyo?”. Rather than sending them a bunch of random links and ideas - they can spin up a canister cloned from my “Tokyo AI Memory” canister and pay me a small fee. Then they can just ask ideas to my AI memory. This is meant to be a viral feature.. so we are not likely going to wait for upstream to find something out in a few weeks for ‘clone canister’.. the original ticket is from 2022 😰 anyone in the community find a work-around that we can use while we wait? @icme ---
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [August 1, 2025, 10:33pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/14 "2025-08-01T22:33:06Z")
@apotheosis How much data is in an AI memory data store? If it’s less than 10-20MB you can probably just spin up a canister and transfer over the relevant parts of that data. This may even be better than a direct clone if you want lent memories to have different logic/restrictions than the original source. Alternatively, instead of spinning up copies of the canister why not just reuse the same canister but put a read only ACL in front of it for those who paid to read from it? ---
**Author:** ![apotheosis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/apotheosis/32/24516_2.png) [@apotheosis](https://forum.dfinity.org/u/apotheosis)\ **Post date:** [August 2, 2025, 11:05pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/15 "2025-08-02T23:05:45Z")
Team was originally thinking of read access. The issue there is that if I copy your data store and pay for it.. but then you alter it.. I wasted my KINIC. Also we want to verify traits of the memories before hand. “Did this data make that prediction?” “Is it about this place?” One other issue is if I was a bad actor I could get read access for 1 KINIC and just DDOS a person’s AI memory. \*burning Cycles gud. I think we will likely do inter-canister call cloning with some bespoke data transfer function. ---
**Author:** ![michael-weigelt](https://avatars.discourse-cdn.com/v4/letter/m/b487fb/32.png) [@michael-weigelt](https://forum.dfinity.org/u/michael-weigelt)\ **Post date:** [September 12, 2025, 1:17pm UTC](https://forum.dfinity.org/t/efficient-ways-to-clone-a-canister-s-data/12066/16 "2025-09-12T13:17:06Z")
Here’s the release announcement: [https://forum.dfinity.org/t/canister-snapshot-up-download/57397](https://forum.dfinity.org/t/canister-snapshot-up-download/57397)