ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    SQL Server Backup Design

    Scheduled Pinned Locked Moved IT Discussion
    sql serverbackup and disaster recoveryveeam backup and replicationvirtualization
    12 Posts 6 Posters 1.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • EddieJenningsE
      EddieJennings @JaredBusch
      last edited by

      @jaredbusch said in SQL Server Backup Design:

      @eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.

      Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.

      Everything else can be rebuilt. It may take more time, but with that .bak file I can bring the business back to life.

      That makes perfect sense. Especially considering "what happens if Veeam gets hosed?" As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?

      EddieJenningsE JaredBuschJ 2 Replies Last reply Reply Quote 0
      • EddieJenningsE
        EddieJennings @EddieJennings
        last edited by

        @eddiejennings said in SQL Server Backup Design:

        @jaredbusch said in SQL Server Backup Design:

        @eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.

        Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.

        Everything else can be rebuilt. It may take more time, but with that .bak file I can bring the business back to life.

        That makes perfect sense. Especially considering "what happens if Veeam gets hosed?" As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?

        Bah. I know the answer to that. It would be dumb to just have those files only in one place, so of course you'd have it local. Ok, time to go home and take a nap. My brain's being dumb.

        DashrenderD JaredBuschJ 2 Replies Last reply Reply Quote 0
        • DashrenderD
          Dashrender @EddieJennings
          last edited by

          @eddiejennings said in SQL Server Backup Design:

          @eddiejennings said in SQL Server Backup Design:

          @jaredbusch said in SQL Server Backup Design:

          @eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.

          Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.

          Everything else can be rebuilt. It may take more time, but with that .bak file I can bring the business back to life.

          That makes perfect sense. Especially considering "what happens if Veeam gets hosed?" As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?

          Bah. I know the answer to that. It would be dumb to just have those files only in one place, so of course you'd have it local. Ok, time to go home and take a nap. My brain's being dumb.

          I wouldn't say it is dumb at all. You should already have a copy inside Veeam, so that's one, plus the live data, plus the place where you put the copy. Who knows, you might not have enough open storage on the local disk to make a copy there.. just a though.

          1 Reply Last reply Reply Quote 0
          • ObsolesceO
            Obsolesce
            last edited by

            I'm with Jared on this one...

            Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.

            Hourly and daily through the SQL backup tools.

            At least daily full VM backup at the hypervisor level.

            I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.

            JaredBuschJ 1 Reply Last reply Reply Quote 2
            • popesterP
              popester
              last edited by

              DILLY DILLY!!! .bak
              I also use the maintenance plans, super easy.

              1 Reply Last reply Reply Quote 0
              • JaredBuschJ
                JaredBusch @EddieJennings
                last edited by

                @eddiejennings said in SQL Server Backup Design:

                @jaredbusch said in SQL Server Backup Design:

                @eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.

                Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.

                Everything else can be rebuilt. It may take more time, but with that .bak file I can bring the business back to life.

                That makes perfect sense. Especially considering "what happens if Veeam gets hosed?" As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?

                Basically yes.

                1 Reply Last reply Reply Quote 0
                • JaredBuschJ
                  JaredBusch @Obsolesce
                  last edited by

                  @tim_g said in SQL Server Backup Design:

                  I'm with Jared on this one...

                  Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.

                  Hourly and daily through the SQL backup tools.

                  At least daily full VM backup at the hypervisor level.

                  I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.

                  I have never had been fail

                  scottalanmillerS 1 Reply Last reply Reply Quote 0
                  • scottalanmillerS
                    scottalanmiller @JaredBusch
                    last edited by

                    @jaredbusch said in SQL Server Backup Design:

                    @tim_g said in SQL Server Backup Design:

                    I'm with Jared on this one...

                    Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.

                    Hourly and daily through the SQL backup tools.

                    At least daily full VM backup at the hypervisor level.

                    I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.

                    I have never had been fail

                    Except for statements like this.

                    JaredBuschJ 1 Reply Last reply Reply Quote 4
                    • JaredBuschJ
                      JaredBusch @EddieJennings
                      last edited by

                      @eddiejennings said in SQL Server Backup Design:

                      @eddiejennings said in SQL Server Backup Design:

                      @jaredbusch said in SQL Server Backup Design:

                      @eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.

                      Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.

                      Everything else can be rebuilt. It may take more time, but with that .bak file I can bring the business back to life.

                      That makes perfect sense. Especially considering "what happens if Veeam gets hosed?" As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?

                      Bah. I know the answer to that. It would be dumb to just have those files only in one place, so of course you'd have it local. Ok, time to go home and take a nap. My brain's being dumb.

                      I use something like crash plan pro on another computer and a hard link to the SQL back up file directory to back it up offsite

                      1 Reply Last reply Reply Quote 0
                      • JaredBuschJ
                        JaredBusch @scottalanmiller
                        last edited by

                        @scottalanmiller said in SQL Server Backup Design:

                        @jaredbusch said in SQL Server Backup Design:

                        @tim_g said in SQL Server Backup Design:

                        I'm with Jared on this one...

                        Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.

                        Hourly and daily through the SQL backup tools.

                        At least daily full VM backup at the hypervisor level.

                        I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.

                        I have never had been fail

                        Except for statements like this.

                        For some reason Siri does not like Veeam yet. Even though correct it a lot

                        1 Reply Last reply Reply Quote 1
                        • 1 / 1
                        • First post
                          Last post