Moving files which were placed directly on HD to GH share

[autumnwalker]

Hi, I'm pretty sure what I'm trying to do is documented in various bits and pieces, but I'm hoping that I can get a concise answer to my specific question.

I have files which were placed locally on the drive by CrashPlan in the folder /var/hda/files/drives/drive1/backups - that folder is part of the GH storage pool; however, it just dawned on me that the files CP is putting in that folder should actually be put through the Samba GH share of /hda/backups.

I would like to mount the shares locally using this wiki article http://wiki.amahi.org/index.php/Mount_Shares_Locally then point CP at the proper share location (/mnt/samba/backup) and have GH look for the files which were already placed in /var/hda/files/drives/drive1/backups.

My questions are:

1) is this possible?
2) besides mounting the shares locally, how do I do the rest of it?

I also assume that CP will need to be shutdown (client / server) while I'm doing all this and give Amahi / GH time to recover from my oversight.

Thanks in advance!

[lrevxl]

I'm not sure if it's well documented, but a few releases back I added in a function to find orphaned files, that is, files which are on one of your storage pool drives, in the right directory structure, but which greyhole doesn't know about, which sounds like exactly what you're looking for. If you look at the greyhole command line options you'll see you can pass an option called '--find-orphaned-files' when you call an fsck, so it'd be something like 'greyhole --fsck --find-orphaned-files' and that should find the files you had been copying there manually.

[autumnwalker]

Thanks! When I run the command I get the following output:

Code: Select all

PHP Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Halifax' for 'ADT/-3.0/DST' instead in /usr/bin/greyhole on line 32 fsck of all shares has been scheduled. It will start after all currently pending tasks have been completed.

I assume this means that it is running the --find-orphaned-files command correctly. When I run greyhole --view-queue it shows an increasing number of writes each time I check.

Is there any way that I can validate that the orphaned files command has executed / completed successfully?

[lrevxl]

Actually, question for you, did you put the files in the landing zone outside of greyhole or on one of the pool drives?

If you put it in the landing zone the command you kicked off will find the new files and create the writes for them. (The --find-orphaned-files command you passed will actually do nothing in this case since it isn't check your storage pool drives.)

If you put it on one of the pool drives you need to give the pool path, so something like 'greyhole --fsck --dir=/path/to/pool/drive/dir --find-orphaned-files'

If you did put it on the storage pool drive and not the landing zone, don't worry, let the fsck finish and then kick off the second command (replacing the --dir option with the correct path).

The best way to figure out what greyhole is doing is to look at the log file (/var/log/greyhole.log)

[autumnwalker]

Actually, question for you, did you put the files in the landing zone outside of greyhole or on one of the pool drives?

If you put it in the landing zone the command you kicked off will find the new files and create the writes for them. (The --find-orphaned-files command you passed will actually do nothing in this case since it isn't check your storage pool drives.)

If you put it on one of the pool drives you need to give the pool path, so something like 'greyhole --fsck --dir=/path/to/pool/drive/dir --find-orphaned-files'

If you did put it on the storage pool drive and not the landing zone, don't worry, let the fsck finish and then kick off the second command (replacing the --dir option with the correct path).

The best way to figure out what greyhole is doing is to look at the log file (/var/log/greyhole.log)

that seemed to do something. files were in /var/hda/files/drives/drive1/backups - pointed it at that and did tail -F /var/log/grayhole.log and it had a lot of activity. didn't take long to execute despite there being several hundred GB of files in there. Log says that it finished... I guess that's it?

[lrevxl]

That depends, do you see the files correctly symlinked in the landing zone?

[autumnwalker]

That depends, do you see the files correctly symlinked in the landing zone?

Good question; how can I tell? (/noob)

I have not moved the default landing zone; however, I told the share to be on /var/hda/files/drives/drive1/backup when I originally set it up, so that would be the LZ for that share, correct? I can see a bunch of files in that directory (using terminal / ssh), but I'm not sure if they are actual files or symlinks.

[lrevxl]

Good question; how can I tell? (/noob)

I have not moved the default landing zone; however, I told the share to be on /var/hda/files/drives/drive1/backup when I originally set it up, so that would be the LZ for that share, correct? I can see a bunch of files in that directory (using terminal / ssh), but I'm not sure if they are actual files or symlinks.

Pretty easy. 'ls -al /var/hda/files/drives/drive1/backup' This command will show you the files and indicate whether the file is a symlink or not.

If the file is a symlink it'll show up as "filename.extension -> /path/to/storage/pool/drive/drives/drive1/backup/filename.extension" which means that the in this case filename.extension in the current directory is actually just a link to the file being pointed at by the "->" symbol. (Directories will not be symlinked, so they'll show up as normal directories still.)

[autumnwalker]

Thank you very much for your help!

The files in the directory show up as symlinks. file.ext -> /var/hda/files/drives/drive1/backups/<CP folder>/file.ext

[lrevxl]

Cool, glad things worked.