Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology definitions deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory object of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorAndrew Stacey
    • CommentTimeNov 9th 2009

    This is closely related to the "Levels of Access" discussion.

    It is obviously important that we keep regular backups of the n-lab, and that several people do so. However, a full backup contains all the information in the database, including the personal webs and the passwords, so there's a question of access here as well.

    There are various options available. The following spring to mind, but there may be others.

    1. Use full backups.
    2. Each web has a full backup of its content.
    3. Each web has a backup of the current content.

    Of course, what we'll do will be a combination of these. Those who would have access to all the data anyway may as well keep a full backup of the whole database: this is also the simplest way of rebuilding the labs in case of a massive systems failure on behalf of our hosts. But due to the security implications, this can't be extended to everyone. On the other hand, there's clearly no problem if everyone has access to a copy of the content (either current or full) of the entire n-lab, but personal web owners may feel differently about their webs.

    Then there's the question of how to get the data. The full database is rather large, and sending it over http is just compounding the problem. The ideal system is simply to update the differences each time: export the content to a version control system and then simply update that each time (I think I got that idea from Jacques somewhere). How difficult would people find that to use? Does anyone have a clue what I'm talking about?

    Remember that as these are backups, it's not important that everyone do it, just that enough people do it.

    • CommentRowNumber2.
    • CommentAuthorUrs
    • CommentTimeNov 9th 2009

    Would it make sense to automatically provide a variety of backup files somewhere where they may be downloaded via sftp as desired?

    • CommentRowNumber3.
    • CommentAuthorAndrew Stacey
    • CommentTimeNov 9th 2009

    This is how we do (or, will do) full backups. To do this, there needs to be a place that both the person downloading the backup and the "mathforge machine" have access to. The obvious place being mathforge itself which means that the person doing the backup needs a secure (ssh) access to it. At the moment, that's in one of the top 3 levels of access.

    The reason I say "do (or, will do)" is that for the top 2 levels of access (currently you, me, and Toby), this is all in place already - I just need to tell you where the files are located on the server and then you can download them whenever you want.

    For the other levels Version Control can work over http and since it wouldn't be a single file of the whole lot, it wouldn't greatly affect our traffic.

    At the moment, though, the precise technicalities are not so important - but perhaps my original post wasn't clear on this. What I'm most interested in is:

    1. Who should and who wants to be part of the backup scheme?
    2. How often should backups be taken?
    3. For those with personal webs, what level of backup do you want? Are you happy being lumped in with the n-lab, or would you rather that only yourself and the top level access people take backups?
    4. How simple do I need to make the backup procedure, noting that there's always a trade-off between simplicity and security?

    (But on that last point, remember that security on the n-lab process is not very tight anyway so making the backups available over a 2048-bit SSL encrypted channel with Implicit Graph Network Disruption Detection is a bit overkill.)

    ((Go on, admit it. Who googled "Implicit graph network disruption detection"?))

    • CommentRowNumber4.
    • CommentAuthorTobyBartels
    • CommentTimeNov 9th 2009

    I just need to tell you where the files are located on the server and then you can download them whenever you want.

    Have you told us? I forget. I haven't been making backups, but I should start to.

    ((Go on, admit it. Who googled "Implicit graph network disruption detection"?))

    Give me a chance! You asked too quickly.

    For those with personal webs

    If they're personal but not very private, then anybody can make a backup (albeit possibly only the hard way, by crawling all of the revision pages, and only the HTML if it's only published). In principle, someone with a personal but world-readable web could request us not to back-up revisions, but making the web world-readable is a much bigger hole. So it's probably really for private (password-protected and not published) webs that we need to clarify this.

    • CommentRowNumber5.
    • CommentAuthorAndrew Stacey
    • CommentTimeNov 9th 2009

    Instructions for getting the full weekly backup are now in the instiki-user help document since that seems the best place to put them.

    • CommentRowNumber6.
    • CommentAuthorTobyBartels
    • CommentTimeNov 9th 2009

    Thanks! I'll have to do that when I have a good connection.

    • CommentRowNumber7.
    • CommentAuthorAndrew Stacey
    • CommentTimeNov 9th 2009

    Just added the daily backup instructions. I had to change a few permissions so it might be 24hrs before the daily backups are available for download. Fortunately, in experimenting I created a new full backup so there's no need to download the dailies until tomorrow. Incidentally, even compressed then the full backup is of the order of 50Mb (dailies are uncompressed and tend to be of the order of a couple of Mbs).

    • CommentRowNumber8.
    • CommentAuthorAndrew Stacey
    • CommentTimeNov 20th 2009

    Bleugh. Just realised that the links to the daily backups were pointing to the current files rather than the ones from the previous day, so they were being updated during the day. Fixed now (I hope).