13 ms·

They should be able to use https://github.com/hartator/wayback-machine-downloader https://github.com/hartator/wayback-machine-downloader and get at least a stat

• DKnoll 9y ago
  If a VPS provider didn't manage to have even an offline backup of their own website they should dissolve the company.
  • rurban 9y ago
    If it was an ex-admin he might have deleted all the backups also. But they should be able to tell this publicly, otherwise it's similar to recent case where the newbie deleted the prod DB without any backup.
    • foepys 9y ago
      Isn't this the time where you put stuff on tape and store it somewhere outside of physical reach? Is tape even used anymore?
      • wlesieutre 9y ago
        Yep, I'm not involved at all but I believe my workplace does its offsite backups on tape with a service like Iron Mountain http://www.ironmountain.com/Services/Data-Management/Tape-Vaulting.aspx http://www.ironmountain.com/Services/Data-Management/Tape-Va...
      • tyingq 9y ago
        A patient disgruntled admin would have altered the backups to write garbage to the tapes for however long the rotation cycle is, then kicked off the production melee.
    • _ph_ 9y ago
      The parent poster talked about an offline backup. That is the big idea of offline (and even better, offsite) backups, that you cannot delete or destroy them from a computer, just by destroying the physical media.
      • shif 9y ago
        An ex admin would probably have access to the physical backups too, this could have been done before he left the company.
        • _ph_ 9y ago
          If he was still a full employee when he wiped the servers, then theoretically yes. It rather sounded to me that he wiped the machines after he left. And off-site backups are often handled by storage companies, making it more difficult to access them.
    • rsync 9y ago
      "If it was an ex-admin he might have deleted all the backups also." One of the very neat things about rsync.net is that your account is on a ZFS platform and you have snapshots enabled by default and the snapshots are totally immutable. Which means that if you back up your VPS (or your VPS company) to an rsync.net account and someone owns you and owns your rsync.net credentials, the worst they can do is delete the very latest backup ... the snapshots cannot be altered. Just saying.
      • rmwaite 9y ago
        So you're telling me if I have a git server (for example) on rsync.net and a newbie developer accidentally commits sensitive credentials there's no way to remove them from the git database? That's very troubling.
        • cstejerean 9y ago
          I think at that point you should just rotate the credentials rather than trying to erase history.
        • mobilethrow 9y ago
          From my understanding of the new EU General Data Protection Rules (GDPR), it will even make rsync.net unusable for most EU companies starting 2018.
          • LeoPanthera 9y ago
            They have a no-snapshots plan, which I am using.
        • ajdlinux 9y ago
          Or, say, one gets sued over information that you're not supposed to have and a court orders you to delete all copies. How do you comply with that?
        • rsync 9y ago
          You misunderstand on several levels here ... First, rsync.net is "cloud storage for offsite backup" - you can't run a git server[1] (or anything else) there. It's not a VPS or a web host. It's a remote unix (ZFS) filesystem that you can access over SSH. The other point you are missing is that the ZFS snapshots I refer to are immutable as far as you are concerned. Of course we can remove them[2], and could do so at your (vetted, verified) request. Further, we don't have unlimited disk space so the snapshots rotate out (expire) over time. Every day the 7th one is removed to make room for the new "yesterday" snapshot, and so on. The point is, an attacker can gain full access to your backups with all of the control you have ever had over them and they can't destroy/delete the snapshots. That would have helped the victim in this story immensely. [1] You can, however, put git repos there and interact with them, using git, over ssh. [2] Although it requires root and is an involved, manual process - which is good.