3 ms·

Redundant online storage sucks, doesn't protect you against DELETE FROM orders WHERE $condition_from_website; So that's just useless. You need offline backu

Redundant online storage sucks, doesn't protect you against DELETE FROM orders WHERE $condition_from_website; So that's just useless. You need offline backups. Is there something like, euhm, perhaps checkpoints, that you can use ?

scarface74 8y ago
Yes, you can schedule automatic snapshots where it will take snapshots on a schedule you choose. You get as much space for your backups as you have in your database for free. Anything above that costs more. You also get point in time recovery with BackTrack. https://aws.amazon.com/blogs/aws/amazon-aurora-backtrack-turn-back-time/ https://aws.amazon.com/blogs/aws/amazon-aurora-backtrack-tur... The redundant storage is what gives you the synchronous read replicas that all use the same storage and the capability of having autoscalinv read replicas that are already in sync.
- creatornator 8y ago
  > automatic snapshots where it will take snapshots on a schedule you choose So... A cronjob?
  - scarface74 8y ago
    Does your cron job allow recovery with a minute granularity? Is your cron job also redundant? How long would it take you to restore from backup?
    - candiodari 8y ago
      You say that as if filesystems with point-in-time and/or checkpoint recovery are anything hard.
      - scarface74 8y ago
        So if it “isn’t hard” then show me an implementation that does that with Mysql that can meet the same recovery time objectives as AWS with Aurora?
        candiodari 8y ago
        Actually with zfs and btrfs you can service mysql stop, put checkpoint back and bring it back up at roughly the same speed as AWS can do it. I also have done enough recoveries to know that actually placing back a checkpoint is admitting defeat and stating that you a) don't know what happened b) don't have any way to fix it And often it means c) don't have any way to prevent it from reoccuring, potentially immediately. It's a quick and direct action that often satisfies the call to action from above. It is exactly the wrong thing to do. It very rarely solves the issue. Actually fixing things mostly means putting the checkpoint on another server, and going through a designed fix process.
        scarface74 8y ago
        You haven’t actually tried using ZfS with Mysql have you? Do you know the drawbacks and performance penalties for doing so? http://download.nust.na/pub6/mysql/tech-resources/articles/mysql-zfs.html http://download.nust.na/pub6/mysql/tech-resources/articles/m... Have you benchmarked the time it takes to bring up a ZFS based Mysql restore? a) don't know what happened b) don't have any way to fix it And often it means c) don't have any way to prevent it from reoccuring, potentially immediately. Can you ensure the filesystem consistency when you restore with ZFS? a) don't know what happened b) don't have any way to fix it And often it means c) don't have any way to prevent it from reoccuring, potentially immediately. In the example that was given in the parent post, we know what happened: Someone inadvertently (hopefully) did Delete * From table You restore the table to the previous state and you take measures to prevent human error.

scarface74 8y ago

Yes, you can schedule automatic snapshots where it will take snapshots on a schedule you choose. You get as much space for your backups as you have in your database for free. Anything above that costs more. You also get point in time recovery with BackTrack. https://aws.amazon.com/blogs/aws/amazon-aurora-backtrack-turn-back-time/ https://aws.amazon.com/blogs/aws/amazon-aurora-backtrack-tur... The redundant storage is what gives you the synchronous read replicas that all use the same storage and the capability of having autoscalinv read replicas that are already in sync.

creatornator 8y ago
> automatic snapshots where it will take snapshots on a schedule you choose So... A cronjob?
- scarface74 8y ago
  Does your cron job allow recovery with a minute granularity? Is your cron job also redundant? How long would it take you to restore from backup?
  - candiodari 8y ago
    You say that as if filesystems with point-in-time and/or checkpoint recovery are anything hard.
    - scarface74 8y ago
      So if it “isn’t hard” then show me an implementation that does that with Mysql that can meet the same recovery time objectives as AWS with Aurora?
      - candiodari 8y ago
        Actually with zfs and btrfs you can service mysql stop, put checkpoint back and bring it back up at roughly the same speed as AWS can do it. I also have done enough recoveries to know that actually placing back a checkpoint is admitting defeat and stating that you a) don't know what happened b) don't have any way to fix it And often it means c) don't have any way to prevent it from reoccuring, potentially immediately. It's a quick and direct action that often satisfies the call to action from above. It is exactly the wrong thing to do. It very rarely solves the issue. Actually fixing things mostly means putting the checkpoint on another server, and going through a designed fix process.
        scarface74 8y ago
        You haven’t actually tried using ZfS with Mysql have you? Do you know the drawbacks and performance penalties for doing so? http://download.nust.na/pub6/mysql/tech-resources/articles/mysql-zfs.html http://download.nust.na/pub6/mysql/tech-resources/articles/m... Have you benchmarked the time it takes to bring up a ZFS based Mysql restore? a) don't know what happened b) don't have any way to fix it And often it means c) don't have any way to prevent it from reoccuring, potentially immediately. Can you ensure the filesystem consistency when you restore with ZFS? a) don't know what happened b) don't have any way to fix it And often it means c) don't have any way to prevent it from reoccuring, potentially immediately. In the example that was given in the parent post, we know what happened: Someone inadvertently (hopefully) did Delete * From table You restore the table to the previous state and you take measures to prevent human error.