Amahi Forums

I have recently (and accidentally) downgraded my greyhole version. After re-installing the newest version it seems as if CrashPlan has made no backup of my data and now it needs to run more than 30 days to make a backup of approx. 2.4TB.

Is there a question here?

Is there a question here?

The title of the thread was an attempt at one I would have liked to know if there is something that the described process could have changed and lead CrashPlan to believe I had no backups in existence. For me it was the first time I encountered this. In parallel I have also asked their support to respond.

In my experience, If you're going to use CrashPlan on your HDA, it's best done without affecting any greyhole-affecting directories.

Crashplan monitors changes to filesystems and greyhole makes changes that are something drastic.

The best approach for using Crashplan with Amahi, is to avoid using greyhole because the changes an additional files end up signaling Crashplan to make drastic reads/writes and the system starts nearly thrashing the folders you're backing up.

Having Crashplan only pull a designated backup partition might be a better idea if you really need greyhole active.

eg:

/var/hda/files/crashplan <-- with no duplication and not part of greyhole

and rsync to a LZ such as
/var/hda/files
which would in turn, offload to the greyhole pool.

... thus allowing a backup solution and greyhole pooling, with or without greyhole duplication.

When setting up crashplan on the HDA, do keep in mind that Crashplan itself allows other machines to backup to your HDA, so you will need sufficient drive space in this supposed /var/hda/files/crashplan partition to accommodate other machine backups too.

But what if I locally mount the shares on my HDA and then have CrashPlan access them?

But what if I locally mount the shares on my HDA and then have CrashPlan access them?

That's where I learned of the issue described...

I wanted my HDA to be backed up and also backup my other PCs, and was overflowing data into a partition, because Crashplan also uses up cache. When Greyhole looks at the Samba file system changes (which will rise quickly with all the Crashplan caching) there are so many that my Greyhole would just crash.

Mind you this was on my Fedora 14 HDA and there could be other factors in this, but all the numerous file system changes are the problem.

I ended up opting for running a separate virtual server with Crashplan on it so that it's isolated and can hold backups and upload backups to cloud without other things in the way.

But what if I locally mount the shares on my HDA and then have CrashPlan access them?

That's where I learned of the issue described...

I wanted my HDA to be backed up and also backup my other PCs, and was overflowing data into a partition, because Crashplan also uses up cache. When Greyhole looks at the Samba file system changes (which will rise quickly with all the Crashplan caching) there are so many that my Greyhole would just crash.

Mind you this was on my Fedora 14 HDA and there could be other factors in this, but all the numerous file system changes are the problem.

I ended up opting for running a separate virtual server with Crashplan on it so that it's isolated and can hold backups and upload backups to cloud without other things in the way.

But I am not using the CrashPlan folder on a pooled drive and am not backing up any other PCs to my HDA. So the only changes are the local Samba mounts. Am I missing something? Is CrashPlan writing into the /mnt/samba/letscallitmedia folder? I thought this would only be mirroring what greyhole writes into the .gh folder on the pooled drives?

When greyhole monitors samba activity, ANY related folders are tracked, which includes locally mounted partitions. It generates a lot of reads and writes.

If your Crashplan folder is within the mounted shares, it SHOULD be fine, but I had some messy activity when I did this because I also wanted the entire shares to be backed up. You may be fine, but I suggest keeping an eye on the size of the crashplan folders and caches.

When greyhole monitors samba activity, ANY related folders are tracked, which includes locally mounted partitions. It generates a lot of reads and writes.

If your Crashplan folder is within the mounted shares, it SHOULD be fine, but I had some messy activity when I did this because I also wanted the entire shares to be backed up. You may be fine, but I suggest keeping an eye on the size of the crashplan folders and caches.

But what I am saying is that I DON'T have the CrashPlan folder in the greyhole pool and that it is not locally mounted under /mnt/samba. So that should be fine, doesn't it?

where is your crashplan folder mounted?