4 ms·
I effectively disabled their deduper early on. That solved a large part of the slow uploads, and as a bonus it also reduced the memory footprint. The latter of
by StillBored 6y ago
I effectively disabled their deduper early on. That solved a large part of the slow uploads, and as a bonus it also reduced the memory footprint. The latter of which is still a problem, but checking my machine at the moment. I see its consuming 10G of address space, but only about 600M are actually resident. I think the 10G number is something I tossed into the config at one point too.
https://support.code42.com/CrashPlan/4/Configuring/Unsupported_changes_to_CrashPlan_de-duplication_settings https://support.code42.com/CrashPlan/4/Configuring/Unsupport...
That means I've probably got a bit of duplication @ crashplan, but given the bulk of the data is a .jpg/mpeg dump from my cameras I don't care about the 5-10% of the archive which isn't compressed and likely has some duplication (the .git repos).
OTOH, crashplan isn't my only backup plan, so if they explode tomorrow I don't think it will cause me any grief outside of having to find another offsite/cloud backup solution.
(also as a further note, looking at my config log, it seems I need /proc/sys/fs/inotify/max_user_watches bumped pretty hard just to keep it running).