![]() That means Code42 is trying to read files over ten or twenty times larger than it expects in search of the blocks. The average user manifests are generally 200-300 MB. However, if you have lots of files selected, and those files have lots of versions, including deleted files, these cache files become larger and larger. ![]() During backup and restore, the manifest files are used to tell what data should be uploaded, and when restoring, what blocks to download, and ultimately, to reform them into your files. During synchronization, the manifests are matched with the caches to make sure they're in agreement. We store versions of the manifests in our servers, and then store local versions on the machine as cache files. Overall this is meant to save time, storage space and to secure your data against cyber attacks. With this setup, we can scan your files and use de-duplication to identify data that has already been backed up, since each split block of data has a unique hash and unique entries in the manifests. We call these files the "manifests" and there are two: one has a basic list of every file being backed up, and another has a history of every version of every file. It then builds two files for its own reference: a table of contents and an index file for your archive. When you start backing up, the Code42 app splits up your original files into blocks of compressed, encrypted data, and uploads it to the archive. In order to solve the problem I will have to go through a much longer explanation with several steps. Unfortunately, it may also take several days, or longer, to fully resolve this issue. In the state this archive is in, I don't believe it is able to Restore any files. It also explains why the files you try to Restore are being displayed at 0 MB: the Code42 app just can't fetch the data on the files and hangs in the attempt. ![]() This because the manifest files it uses to associate its compressed and encrypted backup data with your real files has gotten extremely bloated. Company.Ī quick explanation of the problem is that your archive appears, at this point, to not even be hitting the server because it can't properly load the Restore file tree. TL DR I am being told I have too many files in my archive and that my manifests are too large to recover data, they need to be trimmed by deleting files. To think I was going to backup even more data with them. If anyone considers using this service use this as a warning. I will see what I can download, but I will try to claw back what I have paid them. After 2 days trying to select the files it would show something a message along the lines of `3 files 0 MB Selected` in the logs I contacted support and this is the spiel they gave me. Naturally, I was thinking this wouldn't be a problem this is what cloud backup is made for right?! That was wrong. I just built a new ZFS raidz2 array and decided that I have 40 TB of space now, I will rsync over my existing data, download my 5 TB archive from Crashplan using the app and merge them with what I already have including deleted files. I have been using Crashplan to backup data for about 3 years now if not 4, I was converted from Home to Business when they ended that plan. Just make sure to tag the post with the flair and give a little background info/context. On Fridays we'll allow posts that don't normally fit in the usual data-hoarding theme, including posts that would usually be removed by rule 4: “No memes or 'look at this '”
0 Comments
Leave a Reply. |