Again as the 1st of every month, taken ages to access the various pages on this forum

As usual as happens on the first of every month it’s taken ages to access the various pages on the forum! Just in case any new forum members who may have recently joined this forum!

Regards,

Ian.

  • As I am new here is the first time have experienced it. Took ages to post a video, and to reply here.
  • In reply to William Parsons:

    Avoid the 1st of the month until lunchtime ish :o) (sometimes later!!)
  • In reply to PimperneBloke:

    I agree that backing up the server has to be done on the 1st of the month. Good IT planning and principles. Well done RSPB.

    If it was not done it may affect our posts, and photos we have created if anything went wrong with the servers.

    Regards

    Kathy and Dave

  • In reply to Peewit:

    If it is caused by backups...

    Automated, out-of-hours backups are technically possible. Such things have been done for (literally) decades within the world of IT.
  • In reply to tuwit:

    tuwit said:
    If it is caused by backups...

    Automated, out-of-hours backups are technically possible. Such things have been done for (literally) decades within the world of IT.

    Agreed, and I have suggested it ever since the issue became obvious many years ago. I'd describe the monthly 'outage' as 'housekeeping'. IMO, it's monthly housekeeping which will incl backups but could also incl other stuff like compaction/defrags/optimization etc plus implementations/changes/rollouts etc etc. As it's a UK society, it needs to all be complete by daytime GMT. The 'out of hours' is a valid point, but only if the window is wide/long enough. It may well be automated to run out of hours, but then drag on forever due to inefficiency/bad practice/human error/coding etc. In which case, it needs breaking up or reworking, the former being the quick & easy option. That was fed back years ago, got bogged down with side debates about whether it was or wasn't housekeeping/backups and reached a dead end as no staff took part in the discussion.

  • In reply to ItisaRobbo:

    Remember doing weekly backups in the 90's and the equipment was bit hit and miss at times. Backups failed at times. All was done on Unix.
    All backups where started every Friday night after office hours. Each week a automatic reminder was e-mailed out to all of the workforce reminding them of the situation
    The old Winchester drives and tapes looked and felt clunky to say the least.they where solid heavy metal tapes in cases. Oh the good old days...... LOL
    This was long before Microsoft is used as it is today.

    These days things are so much easier, but sadly backups will always slow down productivity if users are still logged into any IT based system. The work is not be produced/saved as fast as users want so hence the issues going on with the RSPB.

    It is simply just part of the normal with any IT Department.

    Regards

    Kathy and Dave

  • In reply to ItisaRobbo:

    I'd exclude things like defrags nowadays. Haven't touched 'em for two decades. Modern storage devices have advanced a great deal in my lifetime. A lot of disks have their own internal OS's, which handle files, bad sectors, etc.

    Software patches/upgrades should *never* (as in "never ever") be deployed as part of a backup schedule. Why? Patches and upgrades sometimes need to rolled back (reasons: bad implementation planning, unforseen incompatables, "human error") therefore *if* the latest backup is a month ago then it becomes extremely fraught. Over-optimistic roll-back times for failed upgrades/patches can frequently be a cause of system unavailability.

    (ex software developer & system eng & db manager & network eng, etc. Not necessarily in that order or in parallel/tandem.)

    Someone mentioned Winchester. Oh, heck. I remember a head crash that caused a 80's era disk unit to leap across the floor. A bit of a car crash. All that rotational inertia transferred into a line.
  • In reply to tuwit:

    Yes, I'd agree with much of that. I 'will I/won't I' debated with myself as to whether to post anything at all in this thread. In hindsight, I shouldn't have as I've made the point far too often, mostly after at time when I already knew nothing would be rectified.

    Re housekeeping, whether defrags should be included etc, I had finite time, and as it's a bird charity forum, didn't think people wanted scrollable I.T. posts. In fairness to me, I did refer to the housekeeping/backup debate so wanted, in my space & time limiting way, to cover (almost) every aspect to avoid ending up with yet more debates about causation. Some people, no doubt, still don't believe backups are involved. Using the term, 'housekeeping' is even harder to argue against, and I honestly don't mind what aspects people want included or omitted from that 'definition' in 2023.

    As to what is and isn't 'backup schedule', that depends on where in the week monthend occurs (and qtr and year end for that matter). Where I worked, almost all 'changes' (term covered various which I won't try and list this time) just like housekeeping did/does)), were done at weekends, though emergency ones were done overnight during the week occasionally. Some were done at monthend weekends, others on other weekends. Depending on the individuals, on the policy at that time, on 'change window tightness', what's already in the schedule etc etc, extra pre change/implementation/patching/upgrades etc etc backups were done, or weren't. So long as nothing updates stuff between whichever backup and above long list runs, the latest backup is fine to use. Best practice was 'adhoc/dedicated/specfic' pre (and post) backups. Depends on factors incl time, like I said. We ideally ran backups 'stand alone' and change affected systems were entirely unavailable until both backup and then changes were done and signed off. I will draw a line under this now as I'm sure no one else is interested.

    But, two final points.
    1) I re-emphasise that I largely agree with what you wrote.
    2) Dynamic backups (or whichever alternative name people prefer) always ran slower than stand alone ones (which I won't explain). Therefore, if the whole 1st of the month issue is due to long running monthly backup only (as opposed 'other housekeeping'), I would suggest a quick trial using standalone backup instead of dynamic. Very few UK users would notice an entirely unavailable system at 3am GMT.