Hi Vincent,
As per my previous email, this is probably not a great way to back up a fossology database. But it's good functionality to have because we could add a feature that allows users to remove all non-reused files except gold to save disk space. I don't see any bad ramifications except for the user experience (waiting for unpack). The code changes needed in unpack are minimal. All the places in the UI that read files will have to change. So you don't want to create this backup solution until all the code changes are done.

I think you also need to provide user instructions to backup the entire repo. That is:
   stop scheduler
   pg_dumpall > myfile
   backup myfile
   backup repo gold, files, and license
   start scheduler

Bob


On Aug 10, 2009, at 1:31 AM, Ma, Dong (vinc...@gdcc-bj-most) wrote:

Hi Bob,

If no dependencies with the unpacked files at the backup point, I think we should not do unpack on the fly at the restore time. We just restore the gold files and give the user's opinion to unpack the gold files as they needed.
Is this opinion make sense? Or this will bring some bad ramifications?

Thanks,
Vincent


-----Original Message-----
From: Gobeille, Robert
Sent: Friday, August 07, 2009 10:56 PM
To: Ma, Dong (vinc...@gdcc-bj-most)
Cc: [email protected]
Subject: Re: unpack size/time


On Aug 7, 2009, at 2:20 AM, Ma, Dong (vinc...@gdcc-bj-most) wrote:

Hi Bob,

Also have 2 more questions talk with you:
1. Backup all repo files, the incremental disk backup time is not an
issue, but the restore process will also cost so much time when
restore all the repo file every time(one day or more). I just
consider this situation:
        a. only backup gold(and license) files
        b. when restore, only unpack the files which have dependency with
backup point running jobs (if no dependency with running jobs, will
not unpack any gold files in restore)

See previous email.  There are no dependencies from the interrupted
unpack.

        c. unpack other files with user's demand after restore
I am not sure the percentage of 'unpack the files which have
dependency with backup point running jobs' with whole repo unpack
files, if very little unpacked files should be unpacked in restore
process, the time cost will not the issue. May be the time will less
than restore all the repo file.
I hope this question not confuse you.

Restore only the gold (and license) files would typically be much
faster than restoring all the repo files.  Se my previous email in
this thread for times.


2. About ' Allow users to "archive" uploads.', I have a question is
if users have this requirement? If user want this feature of delete
the unpacked files? My thought is the users don't care about
unpacked files occupied how many disk space and want do delete them
if disk spaces is enough.

So far, this has not come up as a user requirement.  The only thing
I've seen from users is the need to delete the entire upload from the
database and repository.   And we already do that.

Bob Gobeille

_______________________________________________
fossology mailing list
[email protected]
http://fossology.org/mailman/listinfo/fossology

Reply via email to