Arch Linux User Repository

@gadicc, I added some pacman hooks to handle setting/unsetting the immutable flag:

Sets immutable flag after install/upgrade:

[Trigger]
Operation = Upgrade
Operation = Install
Type = Package
Target = crashplan-pro

[Action]
Description = Set immutability of Crashplan Pro upgrade directory
When = PostTransaction
Exec = /usr/bin/bash -c "rm -rf /opt/crashplan/upgrade/*; chattr +i /opt/crashplan/upgrade"`

Unsets immutable flag before upgrade/remove:

[Trigger]
Operation = Upgrade
Operation = Remove
Type = Package
Target = crashplan-pro

[Action]
Description = Undo immutability of Crashplan Pro upgrade directory
When = PreTransaction
Exec = /usr/bin/bash -c "chattr -i /opt/crashplan/upgrade"```

It appears that the new package does not overwrite the jre directory. The new version of crashplan bundles JDK11, but the previous jre is 1.8.0_144 which causes the error reported by billyburly.

Hasn't been working since the update to 7. Getting the following error:

<JAVA_HOME>/lib/ext exists, extensions mechanism no longer supported; Use -classpath instead. .Error creating JVM: -1

If you're using lots0logs' new parameters, which work great, to prevent you from having to download the tgz file and calculate the sha256sum, use 5fd8166f3cf7242f8ede9fe225e9fcea1817068069f6ebbdcce64de373d4a17c.

pkgver=7.0.0 _pkgtimestamp=1525200006700 _pkgbuild=581

Updating a few lines in the PKGBUILD will install the latest version, and I can confirm that it appears to operate properly with Code42/Crashplan servers. Line5: pkgver=6.9.4 Line6: _pkgtimestamp=1525200006694 Line7: _pkgbuild=502 Line20: sha256sums=('4defd4d385b77ab19358d8a811ac4eab17aaf8b5928464121cd8b9e516d07055'

@dark-saber, the flag out of date button is perfect for letting them know. :)

CrashPlanSmb_6.9.4_1525200006694_502_Linux.tgz is out.

From an email I received from CrashPlan:

Important Product Update

The CrashPlan for Small Business Code42 app is intended to back up your user’s business files (pictures, music, documents, etc.), not your operating system or applications. For this reason, we have always recommended you not include applications or large files in your selection as they may not backup correctly. We have allowed you to back those things up, but beginning in May 2019, we are making some additional changes to our file exclusions and will be disallowing the backup of applications, VM image files, and some backup files.

After this change is applied, you will likely see your file selection and backup archive size go down and benefit from faster restores, syncs, and backups. The new excludes are listed below and a full list of excludes can be found here (https://support.code42.com/CrashPlan/6/Troubleshooting/What_is_not_backing_up). Applications: /Users/<username>/Applications, /Applications/, /Program Files/, /Program Files (x86)/ VM image files: .hdd, .hds, .pvm, .pvs, .vdi, .vfd, .vhd, .vmc, .vmdk, .vmem, .vmsd, .vmsn, .vmss, .vmtm, .vmwarevm, .vmx, .vmxf, .vsv, .nvram, .vud, .xva Backup files: .bck, .bkf Other files: .tmp, .part, .rbf, .tib, .sparseimage

It just seems unethical to hold data hostage fryfrog, especially for twice the price. But as I said I see that most companies do it now, and it looks like BackBlaze at least demands less ransom than others.

I'll have to think about things for awhile though. Setting and removing the sticky bit isn't that big of a deal, and one of my major concerns is that I have years of backups with CrashPlan, and may have inadvertently or mistakenly deleted data I may need some day. If I move from CrashPlan that data will be gone forever.

Thank you for your suggestions though, as they forced me to look around and see how much the landscape has changed since I last dealt with this issue about 4 years ago.

Unless my calculations are way off... it'd be ~$35/mo to maintain 7T of backup and ~$70 to restore that full 7T.

I think Amazon recently announced a much, much cheaper super deep glacier that has a low per month resting cost, but I didn't see how much it was to restore.