Backup Database SQL Server — คู่มือสำรองข้อมูลฉบับสมบูรณ์ 2026

หลายองค์กรเริ่มนำ Backup Database SQL Server มาใช้อย่างจริงจัง บทความนี้สรุปสิ่งที่ต้องรู้และแนวทางปฏิบัติที่พิสูจน์แล้วว่าได้ผล

ทำไมต้อง Backup Database

ข้อมูลคือทรัพย์สินที่มีค่าที่สุดขององค์กรไม่ว่าจะเป็นข้อมูลลูกค้าข้อมูลการเงินหรือข้อมูลการดำเนินงานถ้าข้อมูลหายไปโดยไม่มี backup ผลกระทบจะรุนแรงมากตั้งแต่สูญเสียรายได้เสียความน่าเชื่อถือไปจนถึงปัญหาทางกฎหมาย

สาเหตุที่ข้อมูลอาจสูญหายมีหลายอย่างเช่น hardware failure (disk เสีย, RAID controller พัง), human error (ลบข้อมูลผิด, DROP TABLE โดยไม่ตั้งใจ), ransomware attack (เข้ารหัสข้อมูลเรียกค่าไถ่), natural disaster (ไฟไหม้, น้ำท่วม datacenter) และ software bug (application เขียนข้อมูลผิด) การมี backup ที่ดีคือหลักประกันว่าคุณสามารถกู้คืนข้อมูลได้ในทุกสถานการณ์

SQL Server เป็น RDBMS ที่นิยมใช้ในองค์กรทั่วโลกมีระบบ backup ที่ครบครันรองรับหลายประเภทตั้งแต่ Full Backup, Differential Backup ไปจนถึง Transaction Log Backup ที่ช่วยให้กู้คืนข้อมูลได้แม่นยำถึงระดับวินาทีบทความนี้จะสอนทุกขั้นตอนตั้งแต่เริ่มต้นจนถึง production-grade backup strategy

ประเภทของ Backup ใน SQL Server

Recovery Model เป็นสิ่งสำคัญที่ต้องเข้าใจก่อนถ้าใช้ Full Recovery Model จะสามารถทำ Transaction Log Backup ได้กู้คืนข้อมูลได้ถึงจุดเวลาที่ต้องการ (Point-in-Time Recovery) แต่ถ้าใช้ Simple Recovery Model จะทำได้แค่ Full และ Differential Backup สำหรับ production database แนะนำ Full Recovery Model เสมอ

Backup ด้วย SSMS (GUI)

วิธีที่ง่ายที่สุดคือใช้ SQL Server Management Studio (SSMS):

1. เปิด SSMS แล้วเชื่อมต่อกับ SQL Server instance
2. คลิกขวาที่ database ที่ต้องการ > Tasks > Back Up...
3. เลือก Backup type: Full, Differential หรือ Transaction Log
4. ตั้ง Destination path สำหรับไฟล์ .bak
5. กด OK เพื่อเริ่ม backup

วิธีนี้เหมาะสำหรับ ad-hoc backup แต่ไม่เหมาะสำหรับ automated backup ที่ต้องทำเป็นประจำเพราะต้องทำด้วยมือทุกครั้งสำหรับ production ควรใช้ T-SQL หรือ SQL Server Agent แทน

Backup ด้วย T-SQL

-- Full Backup
BACKUP DATABASE [MyDatabase]
TO DISK = N'C:\Backup\MyDatabase_Full.bak'
WITH FORMAT, INIT,
NAME = N'MyDatabase-Full',
COMPRESSION,
STATS = 10;

-- Differential Backup
BACKUP DATABASE [MyDatabase]
TO DISK = N'C:\Backup\MyDatabase_Diff.bak'
WITH DIFFERENTIAL, INIT,
NAME = N'MyDatabase-Diff',
COMPRESSION,
STATS = 10;

-- Transaction Log Backup
BACKUP LOG [MyDatabase]
TO DISK = N'C:\Backup\MyDatabase_Log.trn'
WITH INIT,
NAME = N'MyDatabase-Log',
COMPRESSION,
STATS = 10;

ตัวเลือก COMPRESSION สำคัญมากช่วยลดขนาด backup file ได้ 60-80% ประหยัดทั้ง disk space และเวลา backup สำหรับ SQL Server 2016+ มี MAXTRANSFERSIZE ที่ช่วยเพิ่ม performance อีกด้วยตัวเลือก STATS = 10 แสดง progress ทุก 10% ช่วยให้ monitor ได้ว่า backup ใกล้เสร็จแค่ไหน

Automated Backup ด้วย SQL Server Agent

SQL Server Agent เป็น job scheduling service ที่มาพร้อมกับ SQL Server สามารถตั้ง backup job ให้ทำงานอัตโนมัติตาม schedule ที่กำหนด:

1. เปิด SSMS > SQL Server Agent > Jobs > New Job
2. ตั้งชื่อ job เช่น "Daily Full Backup"
3. เพิ่ม Step ประเภท T-SQL ใส่คำสั่ง BACKUP DATABASE
4. ตั้ง Schedule เช่นทุกวันเวลา 02:00 AM
5. ตั้ง Notification ส่ง email เมื่อ job สำเร็จหรือล้มเหลว

Maintenance Plan เป็นอีกทางเลือกที่ง่ายกว่าสร้างผ่าน wizard ใน SSMS โดยไม่ต้องเขียน T-SQL สามารถตั้ง Full Backup ทุกสัปดาห์, Differential Backup ทุกวันและ Transaction Log Backup ทุก 30 นาทีพร้อมลบ backup file เก่าอัตโนมัติ

สำหรับองค์กรที่มี database หลายตัวควรเขียน dynamic T-SQL ที่ loop backup ทุก database อัตโนมัติ:

DECLARE @dbname NVARCHAR(256)
DECLARE @path NVARCHAR(512)
DECLARE @filename NVARCHAR(512)
DECLARE @date NVARCHAR(20)

SET @path = N'C:\Backup\'
SET @date = REPLACE(CONVERT(NVARCHAR(20), GETDATE(), 120), ':', '-')

DECLARE db_cursor CURSOR FOR
SELECT name FROM sys.databases
WHERE state_desc = 'ONLINE'
 AND name NOT IN ('tempdb')

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @dbname
WHILE @@FETCH_STATUS = 0
BEGIN
 SET @filename = @path + @dbname + '_' + @date + '.bak'
 BACKUP DATABASE @dbname TO DISK = @filename WITH COMPRESSION, INIT
 FETCH NEXT FROM db_cursor INTO @dbname
END
CLOSE db_cursor
DEALLOCATE db_cursor

Backup Strategy — 3-2-1 Rule

กฎ 3-2-1 เป็นมาตรฐาน backup strategy ที่ทุกองค์กรควรทำตาม:

• 3 copies — มี backup อย่างน้อย 3 ชุด (original + 2 backup)
• 2 different media — เก็บบน media ต่างชนิดกันเช่น local disk + NAS หรือ local disk + cloud
• 1 offsite — เก็บอย่างน้อย 1 ชุดนอกสถานที่เช่น cloud storage หรือ datacenter อื่น

ตัวอย่าง Backup Schedule สำหรับ Production:

• Full Backup ทุกวันอาทิตย์ 02:00 AM
• Differential Backup ทุกวัน 02:00 AM (จันทร์-เสาร์)
• Transaction Log Backup ทุก 15 นาที
• Copy backup ไป NAS ทุกวันหลัง backup เสร็จ
• Upload Full Backup ไป Azure Blob Storage ทุกสัปดาห์
• ลบ backup file เก่ากว่า 30 วันอัตโนมัติ

สำหรับองค์กรที่มี RPO (Recovery Point Objective) ต่ำมากเช่นระบบการเงินที่ยอมเสียข้อมูลได้ไม่เกิน 5 นาทีควรทำ Transaction Log Backup ทุก 5 นาทีและพิจารณาใช้ Always On Availability Groups ที่ replicate ข้อมูลแบบ synchronous ไปยัง secondary replica แบบ real-time ซึ่งเป็น high availability solution ที่ทรงพลังที่สุดของ SQL Server

อีกสิ่งที่ต้องคำนึงคือ RTO (Recovery Time Objective) หรือเวลาที่ใช้ในการ restore ถ้า database มีขนาด 500GB การ restore Full Backup อาจใช้เวลา 1-2 ชั่วโมงดังนั้นต้องวางแผนว่าองค์กรยอมรับ downtime ได้นานแค่ไหนและเลือก backup strategy ที่ตอบโจทย์ทั้ง RPO และ RTO

Restore Database

Backup ที่ดีต้อง restore ได้ควรทดสอบ restore เป็นประจำอย่างน้อยเดือนละ 1 ครั้ง:

-- Restore Full Backup
RESTORE DATABASE [MyDatabase_Test]
FROM DISK = N'C:\Backup\MyDatabase_Full.bak'
WITH MOVE 'MyDatabase' TO N'C:\Data\MyDatabase_Test.mdf',
MOVE 'MyDatabase_log' TO N'C:\Data\MyDatabase_Test_log.ldf',
NORECOVERY;

-- Restore Differential
RESTORE DATABASE [MyDatabase_Test]
FROM DISK = N'C:\Backup\MyDatabase_Diff.bak'
WITH NORECOVERY;

-- Restore Transaction Log
RESTORE LOG [MyDatabase_Test]
FROM DISK = N'C:\Backup\MyDatabase_Log.trn'
WITH RECOVERY;

Point-in-Time Recovery เป็น feature ที่ทรงพลังมากสามารถกู้คืนข้อมูลถึงเวลาที่ต้องการได้แม่นยำเช่นถ้ามีคนทำ DELETE ข้อมูลผิดตอน 10:30 AM สามารถ restore ถึง 10:29 AM ได้โดยใช้ STOPAT parameter

Backup ไปยัง Cloud Storage

ตั้งแต่ SQL Server 2012 SP1 CU2 รองรับ backup ตรงไป Azure Blob Storage โดยไม่ต้อง backup ลง local disk ก่อน:

-- สร้าง Credential
CREATE CREDENTIAL [AzureBackupCredential]
WITH IDENTITY = 'mystorageaccount',
SECRET = 'YOUR_STORAGE_ACCESS_KEY';

-- Backup ไป Azure
BACKUP DATABASE [MyDatabase]
TO URL = 'https://mystorageaccount.blob.core.windows.net/sqlbackup/MyDatabase.bak'
WITH CREDENTIAL = 'AzureBackupCredential',
COMPRESSION, STATS = 10;

สำหรับ AWS สามารถใช้ AWS RDS ที่มี automated backup built-in หรือใช้ AWS S3 ร่วมกับ SQL Server Agent ที่ backup ลง local แล้ว upload ด้วย AWS CLI ทั้ง Azure และ AWS มี lifecycle policy ที่ย้าย backup เก่าไป cold storage อัตโนมัติเพื่อประหยัดค่าใช้จ่าย

Monitoring และ Alerts

การ backup ที่ไม่มี monitoring เท่ากับไม่มี backup เลยเพราะถ้า backup ล้มเหลวแล้วไม่มีใครรู้เมื่อต้องการ restore จะพบว่าไม่มี backup ที่ใช้ได้:

• ตรวจสอบ backup history — query จาก msdb.dbo.backupset เพื่อดูว่า backup สำเร็จเมื่อไหร่ขนาดเท่าไหร่
• Database Mail — ตั้งค่า email alert เมื่อ backup job ล้มเหลวให้ส่ง email ถึง DBA ทันที
• Monitoring Dashboard — ใช้ Grafana + Prometheus หรือ Zabbix monitor backup status แสดงเป็น dashboard
• Retention Policy — ตรวจสอบว่า backup file เก่าถูกลบตาม policy ไม่ให้ disk เต็ม

-- ตรวจสอบ backup ล่าสุดของทุก database
SELECT d.name AS DatabaseName,
 MAX(b.backup_finish_date) AS LastBackupDate,
 DATEDIFF(HOUR, MAX(b.backup_finish_date), GETDATE()) AS HoursSinceLastBackup
FROM sys.databases d
LEFT JOIN msdb.dbo.backupset b ON d.name = b.database_name
GROUP BY d.name
ORDER BY LastBackupDate;

Best Practices

• ใช้ COMPRESSION เสมอ — ลดขนาด backup file 60-80% ประหยัด disk และเวลา
• ทดสอบ Restore เป็นประจำ — backup ที่ไม่เคยทดสอบ restore เท่ากับไม่มี backup
• ใช้ CHECKSUM — เพิ่ม WITH CHECKSUM เพื่อตรวจสอบ integrity ของ backup file
• ตั้ง Alerts — รู้ทันทีเมื่อ backup ล้มเหลวอย่ารอจนต้อง restore แล้วค่อยรู้
• เข้ารหัส Backup — ใช้ WITH ENCRYPTION (SQL Server 2014+) ป้องกัน backup file ถูกอ่านโดยคนที่ไม่ได้รับอนุญาต
• แยก Backup Disk — อย่า backup ลง disk เดียวกับ data file ถ้า disk เสียจะเสียทั้ง data และ backup
• Document Recovery Plan — เขียน runbook สำหรับ disaster recovery ให้ทุกู้คืนในทีมอ่านและทำตามได้
• ใช้ VERIFY หลัง Backup — เพิ่ม RESTORE VERIFYONLY FROM DISK = N'path.bak' หลัง backup เสร็จทุกครั้งเพื่อตรวจสอบว่า backup file ไม่ corrupt และสามารถ restore ได้จริง
• แยก TempDB ออกจาก Data Disk — TempDB ที่อยู่บน disk เดียวกับ data file จะทำให้ backup ช้าลงแยก TempDB ไป disk อื่นจะช่วยเพิ่ม performance ทั้ง backup และ query

สำหรับ SQL Server 2022 ขึ้นไปมี feature ใหม่ที่น่าสนใจคือ Backup to S3-compatible storage ที่รองรับ backup ตรงไป MinIO, Wasabi หรือ S3-compatible storage ใดๆทำให้ไม่จำกัดแค่ Azure Blob Storage อีกต่อไปนอกจากนี้ยังมี Integrated Acceleration and Offloading ที่ใช้ hardware acceleration สำหรับ backup compression ทำให้เร็วขึ้นอีกหลายเท่า

อีกเทคนิคที่สำคัญคือ Striped Backup ที่แบ่ง backup ออกเป็นหลายไฟล์พร้อมกันช่วยเพิ่มความเร็วในการ backup database ขนาดใหญ่ได้มากเช่น database 1TB อาจ backup เสร็จใน 30 นาทีแทนที่จะเป็น 2 ชั่วโมงโดยใช้ 4 backup files พร้อมกัน

Full Backup กับ Differential Backup ต่างกันยังไง?

สรุปแล้วบทความนี้ครอบคลุมทุกอย่างที่คุณต้องรู้หากมีคำถามเพิ่มเติมสามารถติดต่อผ่านทาง SiamCafe ได้ทันทีขอบคุณที่อ่านบทความนี้จนจบครับ