Phastor

Any plans for it in the future, if it's even possible?

Does Scatter follow allocation method and directory split levels?

Trying to browse through folders under the Restore tab is painful. Every time you try to drill down a folder it takes nearly two minutes to think before it actually does it. Doesn't matter how large or how many files are in the folder. It does this with every single folder--and it seems to get longer with every additional snapshot taken. Is this normal?

I have one drive with an existing set of backups on it. I want to make a second so I can rotate them to have an off-site cold backup. I really don't want to take another three days to generate another backup of my 1.7TB from scratch on another drive, so I had the idea copying the backups from one drive to another (a few hours of work rather than days) and exporting/importing it's configuration and changing the name and destination. I know you could move backups to another location by doing this, but what about making an exact copy? Could two exact instances of the same backups exist under different names? To test if this would work, I made a small test backup set. I ran it once and copied the resulting backups to another location. I then exported the configuration for that backup and imported it into another new set under a different name. I changed the destination to the location that I made the copy of the backup to and tried running it. It failed the first time, referencing files on the remote location that didn't match. After running a repair on it, it ran successfully on the second attempt. So now that I know this works, before I go an do this with my live backup, I just wanted to make sure that I won't run into any wonky issues later on?

Yeah, I never looked into whether Cloudberry supported it or not until now. I guess it just doesn't fit my use case. It's shame since I really like it! I guess I'm stuck with the slowness of Duplicati.

Thanks for the quick timzone fix! Partially for the space, partially for the backup duration, and mostly because my backup drive can't hold more than one copy of my video. I suppose I could create a separate backup plan for video that immediately removes files that were locally deleted. However, if I were to move a video, the software will still want to create a backup of that video in it's new location before deleting the old, right? Just renaming the top level directory of my video files would trigger a full copy of every video, unless I'm misunderstanding this. At over a TB of video, that would be a long backup for a small change.

Eew. Just changing the filename (or that of its parent folder) or moving a file triggers a full duplicate instance of that file in the backup. Since most of my data is decently large video files, that's a deal breaker for me. I understand that's a limitation of the software itself and not the docker container. Thanks anyway for your help on this!

I just did another backup attempt with "Always keep the last version" selected. That seemed to fix it. It retained everything this time. I figured it would have have hung onto everything without that selected as long as the backups were not older than a month. Does it determine this by the files last modify date rather than the time of the backup that it was actually taken? And I have the same issue 1812's comment above. The time is off.

Filtered by Purge and found that they are indeed being purged after the backup. I have my retention set to keep backups going back to a month. Shouldn't it only be doing this to file versions that are older than a month?

While going in to restore within Cloudberry, the only files available to retore are those that I see when manually looking through the target drive. Just the ones that it didn't delete after completing the backup.

Well, it just got weirder. During the second backup, I watched the target drive as the files were added. It actually does appear to backup everything selected, but then deletes them from the target after the backup completes. It only left the files that were there after the first attempt. The files in this test backup range between a few KB (documents), to a couple GB (short video). The test backup as a whole is about 100GB.

Starting testing this out. Seems like my choice lies between this and Duplicati. Completed my first test backup and it seems to have skipped over a lot of files. Many things are missing in the backup target. I'm running the backup again and it seems to be picking up what it missed, but now I'm wondering if it will still miss things on this pass. Has anyone else seen this? I'm hoping this is something that can be fixed, because I'm already impressed at the speed that it runs at going to my USB3 drive compared to Duplicati.

I wouldn't take a large issue with full file versions being taken when changed since I mostly have audio and video. The only changes made to those are renames and relocation, which I would imagine and hope it wouldn't take full versions for that.

I might have to take a look at Cloudberry then. I have another drive I can test it with without losing what I've done so far with Duplicati. Would be great if it can address the speed issue, but another thing I would love if it has a restore option to ignore files that already exist. Duplicati only offers the option to overwrite or create duplicate. Does Cloudberry do this?

I'm actually using USB3. The actual transfer of the remote volumes to the drive are pretty quick. Each 250 MB volume only takes a couple seconds to be moved to the drive. It's the creation of the volumes before they are flushed to the drive that takes forever. Each volume is generated at about 10 MB/s.

I just completed my first backup of 1.7 TB to a USB3 drive. I'm running 500KB blocks, 250MB remote volumes and no encryption. The rest of my settings are default. It took 2d18h to complete. I've used solutions that were slower, but this still concerns me unless someone here can verify that this is expected. I did a test restore after the backup completed. The first thing I noticed was how slow it was to browse through the backups. It took 30-45 seconds to expand each directory that I drilled down through. I chose a 7GB file to test with, which took about 20 minutes to restore. From what I observed with the information the UI provides, the actual restoration of the file took about three minutes while the rest of the time was spent verifying before and after. Is all this kind of behavior typical with Duplicati, or is there something I could be doing wrong?

I kept the volume size 50MB and did another test. Backup seems to be going really slow as it did about 30GB in two hours. I set it to 1GB just for testing and got the same results. I monitored the shares as the backup was happening and it seems that the slowness is occurring during the generation of the zip files. It takes about 90 seconds to generate one of the 1GB volumes. Transfer to the USB drive seems fine as it only takes about 10 seconds to copy the file to the drive after it's generated. I disabled compression thinking that might speed things up. Most of my files are audio and video, so I won't benefit much from compression. I'm not really noticing any difference even after doing that. Is there any way I can speed that up?

I have a top level share called "backups" that I keep copies of my game server saves in and the Veeam archives for my workstations. That share is allocated to cache only, so based on what I heard here, I decided to put a tmp folder under that and map /tmp to that. Next question: I did a test run and the first thing I noticed were the tons upon tons of 50 MB zip files going onto my external backup drive. I did some reasearch and learned about remote volumes. From what I understand, the default size of these volumes were set to 50 MB with it in mind that the smaller sizes would be easier to move up and down to cloud services. Given that I eventually fill my 8 TB and am backing it all up, that puts it in the ballpark of around 160,000 of these little guys sitting on that drive. I don't intend to push my backups to the cloud, and instead plan stick with a couple USB drives that I rotate so that I can have one off-site. With this in mind, should I set the remote volume size to something larger? The majority of what I'm backing up is audio and video if that's a factor. And the same as a couple other people have stated here, I'm here now because of Crashplan deciding to crap on their home users.

Where's a good place to map /tmp? Does it get large? Would I be able to map it to something like /user/appdata/duplicati/tmp without an issue?

For some reason, Crashplan isn't backing up on the schedule I've given it. I'm aware that there isn't a way to tell it to run a backup "at this exact time," but I wanted it to run a backup at around midnight. I've set the "Backup will run" setting between 12:00AM and 3:30AM. I've noticed so far it has not backed up during this window at all. It's backed up one time outside of that window and now there hasn't been a backup at all within the last 24 hours. Under the summary it does say that backup is scheduled to begin at 12:00 AM. It also says that a backup was done in the last 11 hours, but I find that hard to believe since I don't see any files in the backup that I've uploaded to my shares before that time. I've included a shot of my schedule and frequency/retention policy. Am I missing something?

Yup! This is what I was thinking. I've got appdata and my flash already backed up on a nightly schedule. I'll remove the docker image from backup then. As far as VMs, I don't have any yet. I'll probably spin up an ARK and Minecraft server sometime down the road. I might not map their data to an unRAID share directly, but I do plan for them to back up their world files on a regular basis somewhere to a share, which will then get picked up by Crashplan. I wouldn't backup the VMs themselves then since it shouldn't be too difficult to spin up new ones and restore their data.

Straight and to the point. Thanks! Can the same be said for the libvirt image and pretty much the system share as a whole?

Since it's always changing, it gets flagged for backup every night by Crashplan. At this rate, at 20 GB a night, I'm going to have over 600GB in versions of the same file in a month's time. It also extends my backup time by some margin. Does this even need to be backed up? We all already know that settings, configs, and other data for dockers are in appdata, and from what I can tell, templates for previously installed dockers are stored on flash. I'm already backing up both of these locations, so really if I were to lose my cache drive, I could theoretically rebuild all of my dockers from those templates and appdata really easily. That being said, is there any reason at all why I should be backing up the image?