SQL Server backup და აღდგენა: .bak ფაილები Agent-ის გარეშე

SQL Server-ის backup ერთი ინსტრუქციაა: BACKUP DATABASE [appdb] TO DISK = N'/path/appdb.bak' WITH CHECKSUM, INIT;. ის ბაზის თანმიმდევრულ ასლს ერთ .bak ფაილში წერს, სანამ ბაზა ტრაფიკს ჩვეულებრივ ემსახურება, RESTORE DATABASE კი მას უკან აბრუნებს - იმავე სერვერზე ან ნებისმიერ სხვა SQL Server-ზე, იმავე ან უფრო ახალი ვერსიით. რაზეც ხალხი ბორკილდება, ამ ინსტრუქციის გარშემოა და არა მასში: Express-ს არ აქვს SQL Server Agent მის დასაგეგმად, ფაილი სერვერის დისკზე ხვდება და არა შენსაზე, სხვა სერვერზე აღდგენას WITH MOVE სჭირდება, აღდგენილი login-ები კი თავიანთ user-ებს მოწყვეტილი მოდის.

ეს გზამკვლევი ყველაფერს ფარავს SQL Server 2022-ისთვის, Express ედიციის შეზღუდვებით იქ, სადაც ისინი მნიშვნელოვანია. მისი უმეტესი ნაწილი უცვლელად ეხება 2016-დან 2019-მდე ვერსიებს და Windows-საც, Linux-ის გარდა.

რას შეიცავს native backup#

BACKUP DATABASE ფაილის კოპირება არ არის. SQL Server კითხულობს ყოველ გამოყოფილ მონაცემთა გვერდს, შემდეგ კი უმატებს transaction log-ის იმდენ ნაწილს, რომ ასლი თანმიმდევრული იყოს backup-ის დასრულების მომენტისთვის. აღდგენისას ძრავი ამ log-ის ნაწილს ხელახლა ასრულებს და უკან აბრუნებს ყველაფერს, რაც commit-ი არ ყოფილა. შედეგი არის ბაზა, რომელიც ერთ მომენტში არსებობდა, ყველა foreign key-ით ხელუხლებლად - ზუსტად ის, რასაც გაშვებული სერვერიდან აღებული .mdf ფაილის ასლი ვერ დაგპირდება.

backup-ის სამი ტიპი არსებობს და Express სამივეს მხარს უჭერს:

differential კუმულაციურია და არა ინკრემენტული: ოთხშაბათის differential შეიცავს ყველაფერს, რაც კვირის full-ის შემდეგ შეიცვალა, იმის ჩათვლით, რაც ორშაბათისა და სამშაბათის ასლებს უკვე ჰქონდა. აღდგენას სჭირდება full და მხოლოდ ერთი, ყველაზე ახალი differential. Log backup-ები პირიქითაა - თითოეული მხოლოდ თავის დროის მონაკვეთს შეიცავს და კონკრეტულ მომენტზე აღდგენას უწყვეტი ჯაჭვი სჭირდება. საერთოდ გჭირდება თუ არა ისინი, recovery model-ზეა დამოკიდებული, რასაც SQL Server-ის recovery model-ები და log-ის ზრდა დეტალურად განიხილავს. 10 GB-ზე ნაკლები ბაზისთვის ღამის full backup-ით და ერთი საათის დასაშვები დანაკარგით მხოლოდ full backup-ები სავსებით ღირსეული გეგმაა.

რასაც backup არ შეიცავს, არის ყველაფერი ბაზის გარეთ. Login-ები master-ში ცხოვრობს, job-ები msdb-ში, სერვერის პარამეტრები კი ინსტანციაში. appdb-ის .bak, სხვაგან აღდგენილი, თან მოიტანს ბაზის user-ებს, მაგრამ არა login-ებს, რომლებზეც ისინი მიბმულია. ეს აღდგენის შემდეგ ყველაზე ხშირი სიურპრიზია და ქვემოთ ცალკე სექცია აქვს.

Full backup-ის აღება#

დაუკავშირდი sa-თი ან ნებისმიერი login-ით, რომელსაც ბაზაზე db_backupoperator აქვს, და გაუშვი:

BACKUP DATABASE [appdb]TO DISK = N'/var/opt/mssql/data/appdb-2026-10-08.bak'WITH CHECKSUM, INIT, STATS = 10,     NAME = N'appdb full 2026-10-08';

რას აკეთებს თითოეული ოფცია:

• CHECKSUM - კითხვისას ამოწმებს გვერდების checksum-ებს და მთელ backup-ზე checksum-ს წერს. თუ რომელიმე გვერდი უკვე დაზიანებულია, backup ჩავარდება და დაზიანებას ჩუმად არ შეინახავს. მისი გამოტოვების კარგი მიზეზი არ არსებობს.
• INIT - გადაწერს ფაილში უკვე არსებულ backup set-ებს. მის გარეშე SQL Server ფაილს ბოლოში უმატებს, და .bak, რომელსაც წლის განმავლობაში ყოველ ღამე უმატებდნენ, 300 GB-იანი სიურპრიზია 365 backup-ით შიგნით. გამოიყენე ახალი ფაილის სახელი თითო backup-ზე და INIT, ან ერთი ფაილის სახელი და INIT - მაგრამ შემთხვევით ბოლოში დამატება არასოდეს.
• STATS = 10 - ყოველ 10 პროცენტზე პროგრესს ბეჭდავს, და ასე არჩევ ნელ backup-ს გაჭედილისგან.
• COPY_ONLY - დაამატე ეს ერთჯერად backup-ს, რომელსაც ჩვეულებრივი განრიგის გარეთ იღებ. ის differential-ის საფუძველს არ აბრუნებს თავიდან, ამიტომ შემდეგი დაგეგმილი differential კვლავ დაგეგმილ full-თან წყვილდება და არა შენს ერთჯერად ასლთან.

გზა სერვერზეა. ამის გამეორება ღირს, რადგან ყველას აბნევს, ვინც პირველად თავისი ლეპტოპის SSMS-იდან უშვებს backup-ს: TO DISK-ს SQL Server-ის პროცესი ხსნის, იმ მანქანაზე, სადაც SQL Server მუშაობს. C:\Backups\appdb.bak-ის მსგავსი გზა Linux სერვერზე შენი C: დისკი არ არის. იმის გასაგებად, სად ინახავს სერვერი backup-ებს ნაგულისხმევად:

SELECT SERVERPROPERTY('InstanceDefaultBackupPath') AS backup_dir,       SERVERPROPERTY('InstanceDefaultDataPath')   AS data_dir;

InstanceDefaultBackupPath SQL Server 2019-დან არსებობს. სტანდარტულ Linux ინსტალაციაზე ორივე ჩვეულებრივ /var/opt/mssql/data/-ზე მიუთითებს, თუ ვინმემ ისინი mssql-conf-ით არ შეცვალა. Linux-ზე SQL Server-ის პროცესი mssql მომხმარებლით მუშაობს და მას ჩაწერის უფლება სჭირდება ნებისმიერ დირექტორიაზე, რომელსაც დაასახელებ.

Backup-ის შემოწმება, სანამ დაგჭირდება#

backup ფაილი, რომელიც არასოდეს წაუკითხავთ, ჰიპოთეზაა. SQL Server სამ იაფ შემოწმებას გაძლევს და არცერთი მათგანი ცოცხალ ბაზას არ ეხება:

-- Is the file readable and complete? Checks the checksums too.RESTORE VERIFYONLYFROM DISK = N'/var/opt/mssql/data/appdb-2026-10-08.bak'WITH CHECKSUM;-- What is in the file: database name, type, dates, version.RESTORE HEADERONLYFROM DISK = N'/var/opt/mssql/data/appdb-2026-10-08.bak';-- Which data and log files the database had, by logical name.RESTORE FILELISTONLYFROM DISK = N'/var/opt/mssql/data/appdb-2026-10-08.bak';

VERIFYONLY ამტკიცებს, რომ ფაილი მთელია. ის არ ამტკიცებს, რომ შიგნით არსებული ბაზა ჯანმრთელია - ბაზა, რომელიც backup-მდე ლოგიკურად იყო დაზიანებული, ერთგულად დაარქივდება. ერთადერთი ნამდვილი ტესტი ფაილის ახალი სახელით აღდგენა და ასლზე DBCC CHECKDB-ის გაშვებაა:

DBCC CHECKDB (N'appdb_verify') WITH NO_INFOMSGS, ALL_ERRORMSGS;

გამოტანის არარსებობა შეცდომების არარსებობას ნიშნავს. შემდეგ ასლი წაშალე. 10 GB-იან Express ბაზაზე ამას წუთები სჭირდება, და თვეში ერთხელ ამის გაკეთება არის განსხვავება backup-ების ქონასა და იმის რწმენას შორის, რომ გაქვს. აღდგენის ტესტირება, სანამ დაგჭირდება ზოგად არგუმენტს ასაბუთებს.

backup-ების ისტორია msdb-შია, რაც სასარგებლოა იმის შესამოწმებლად, მართლა გაეშვა თუ არა დაგეგმილი job-ი:

SELECT TOP (20) database_name, type, backup_start_date,       backup_finish_date, backup_size / 1048576 AS size_mb,       physical_device_nameFROM msdb.dbo.backupset AS bJOIN msdb.dbo.backupmediafamily AS m ON m.media_set_id = b.media_set_idORDER BY backup_finish_date DESC;

type არის D full-ისთვის, I differential-ისთვის და L log-ისთვის.

აღდგენა: იმავე სერვერზე, ახალი სახელით ან სხვა სერვერზე#

აღდგენისას მნიშვნელობას იძენს FILELISTONLY-ის ლოგიკური ფაილის სახელები. ბაზას მინიმუმ ერთი მონაცემთა ფაილი და ერთი log ფაილი აქვს, თითოეულს ლოგიკური სახელით (მაგალითად appdb და appdb_log) და ფიზიკური გზით. აღდგენა ფაილების თავდაპირველ ფიზიკურ გზებზე დაბრუნებას ცდილობს, თუ სხვა რამ არ უთხარი, და ეს ჩავარდება, თუ ეს გზები დაკავებულია ან ამ მანქანაზე არ არსებობს.

ორიგინალის გვერდით ახალი სახელით აღსადგენად - ეს არის წაშლილი ცხრილის დაბრუნების უსაფრთხო გზა production-ზე შეხების გარეშე:

RESTORE DATABASE [appdb_restore]FROM DISK = N'/var/opt/mssql/data/appdb-2026-10-08.bak'WITH MOVE N'appdb'     TO N'/var/opt/mssql/data/appdb_restore.mdf',     MOVE N'appdb_log' TO N'/var/opt/mssql/data/appdb_restore_log.ldf',     RECOVERY, STATS = 10;

შემდეგ საჭირო row-ები ორ ბაზას შორის ჩვეულებრივი INSERT ... SELECT-ით უკან გადაიტანე და appdb_restore წაშალე.

ორიგინალის გადასაწერად ექსკლუზიური წვდომა გჭირდება. ბაზასთან ყოველი კავშირი, მათ შორის ის, რომელიც შენს SSMS-ის query ფანჯარას აქვს გახსნილი, აღდგენას ბლოკავს:

USE master;ALTER DATABASE [appdb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;RESTORE DATABASE [appdb]FROM DISK = N'/var/opt/mssql/data/appdb-2026-10-08.bak'WITH REPLACE, RECOVERY, STATS = 10;ALTER DATABASE [appdb] SET MULTI_USER;

ROLLBACK IMMEDIATE ყველას თიშავს და მათ ღია ტრანზაქციებს უკან აბრუნებს. REPLACE SQL Server-ს ეუბნება, რომ მართლა გინდა არსებული ბაზის გადაწერა; მის გარეშე ბაზაზე აღდგენა, რომლის log-ის backup-იც არ აღებულა, ჩერდება შეცდომით 3159 და ჯერ tail-log backup-ს ითხოვს.

Windows-ზე აღებული backup Linux-ზე აღდგება და პირიქით. ფაილის ფორმატი იგივეა, მხოლოდ გზები განსხვავდება, ამიტომ ყოველი ფაილი MOVE-ით Linux-ის გზაზე გადაიტანე. ვერსიის წესი ერთი მიმართულებით მკაცრია: backup აღდგება იმავე ან უფრო ახალ ვერსიაზე, ძველზე არასოდეს. SQL Server 2022-ის backup 2019-ზე არ აღდგება, რაც არ უნდა სცადო. ვერსიით დაბლა ჩასასვლელად BACPAC ან სკრიპტები გჭირდება, და ორივე განხილულია სტატიაში ბაზის მიგრაცია SQL Server ჰოსტინგზე.

ოფცია RECOVERY ასრულებს აღდგენას და ბაზას ხსნის. NORECOVERY მას "Restoring..." მდგომარეობაში ტოვებს, რომ შემდეგი backup-ები დაემატოს - differential, შემდეგ log backup-ები. თუ ბოლო RECOVERY დაგავიწყდა, ბაზა იქ დგას და გაჭედილს ჰგავს; ცალკე RESTORE DATABASE [appdb] WITH RECOVERY; მას ასრულებს.

Login-ები, user-ები და ობოლი user-ის პრობლემა#

ბაზის შიგნით user სერვერის login-ს უკავშირდება უსაფრთხოების იდენტიფიკატორით (SID). SQL authentication-ით შექმნილი login-ები ყოველ სერვერზე შემთხვევით SID-ს იღებს. აღადგინე ბაზა სხვა სერვერზე, შექმენი იმავე სახელის login-ი, და user და login-ი მაინც არ ემთხვევა ერთმანეთს: user ობოლია, აპლიკაცია კი იღებს Login failed for user 'app'-ს, თუმცა ორივე არსებობს.

აღდგენილ ბაზაში ობლების პოვნა:

SELECT dp.name AS user_name, dp.sidFROM sys.database_principals AS dpLEFT JOIN sys.server_principals AS sp ON sp.sid = dp.sidWHERE dp.type = 'S'  AND sp.sid IS NULL  AND dp.authentication_type_desc = 'INSTANCE';

თითოეული გაასწორე login-ზე მიმართვით:

ALTER USER [app] WITH LOGIN = [app];

ძველი პროცედურა sp_change_users_login იმავე საქმეს აკეთებს და მოძველებულად არის გამოცხადებული; გამოიყენე ALTER USER. დაგეგმილი გადატანისას პრობლემის სრულად ასარიდებლად ახალ სერვერზე login-ი ორიგინალური SID-ით შექმენი (CREATE LOGIN [app] WITH PASSWORD = '...', SID = 0x...), SID კი ძველი სერვერის sys.server_principals-დან აიღე. SQL Server-ის login-ები, user-ები და როლები ამ მოდელს სათანადოდ ხსნის.

Backup-ების დაგეგმვა, როცა SQL Server Agent არ არის#

Standard და Enterprise ედიციებზე ღამის backup-ს SQL Server Agent-ის job-ი ან maintenance plan უშვებს. Express-ს SQL Server Agent საერთოდ არ აქვს, არც Windows-ზე და არც Linux-ზე, ამიტომ განრიგი ძრავის გარედან უნდა მოვიდეს. ეს იმაზე ნაკლები შეზღუდვაა, ვიდრე ჟღერს: backup ერთი ინსტრუქციაა და ყველაფერს, რასაც ტაიმერით sqlcmd-ის გაშვება შეუძლია, მისი აღებაც შეუძლია.

backup ჩადე სკრიპტში, რომელიც ფაილს თარიღით ასახელებს:

DECLARE @file nvarchar(400) =    N'/var/opt/mssql/data/appdb-' + CONVERT(char(8), SYSUTCDATETIME(), 112) + N'.bak';BACKUP DATABASE [appdb] TO DISK = @fileWITH CHECKSUM, INIT, STATS = 25;

შემდეგ გაუშვი ის ნებისმიერი მანქანიდან, რომელიც სერვერს წვდება - შენი საკუთარი Linux მანქანიდან, პატარა აპლიკაციის სერვერიდან, CI job-იდან:

$ export SQLCMDPASSWORD='the-generated-sa-password'$ sqlcmd -S db.example.net,14330 -U sa -C -b -i backup.sql -o backup.log

-b აიძულებს sqlcmd-ს, შეცდომისას არანულოვანი კოდით გავიდეს, ამიტომ cron-ი ან CI runner-ი ჩავარდნილ backup-ს კარგისგან გაარჩევს. -C სერვერის სერტიფიკატს ენდობა, რაც version 18-ის ინსტრუმენტებს სჭირდება, რადგან ისინი ნაგულისხმევად შიფრავენ; flag-ებს sqlcmd და bcp განიხილავს. crontab-ის ხაზი შემდეგ ჩვეულებრივია:

15 3 * * * /usr/local/bin/sql-backup.sh >> /var/log/sql-backup.log 2>&1

Windows-ზე იმავე საქმეს Task Scheduler აკეთებს, რომელიც იმავე sqlcmd ხაზს უშვებს. რაიმე უფრო რთულისთვის - რამდენიმე ბაზა, differential-ები სამუშაო დღეებში, ძველი ფაილების წაშლა - Express-ზე სტანდარტული პასუხი Ola Hallengren-ის უფასო maintenance solution-ია: ერთხელ დააყენე მისი stored procedure-ები, შემდეგ კი შენი დაგეგმილი sqlcmd-იდან შიშველი BACKUP-ის ნაცვლად გამოიძახე dbo.DatabaseBackup. ის წლებია, რაც Linux-ზე SQL Server-ს უჭერს მხარს; მის დოკუმენტაციაში შეამოწმე, გაწმენდის რომელი ოფციები მუშაობს იქ.

ამ მოწყობაში ორი რამის გამორჩენა ადვილია. backup ფაილი მაინც ბაზის სერვერის დისკზე იწერება და არა იმ მანქანაზე, რომელიც sqlcmd-ს უშვებს, ამიტომ მისი გაწმენდა იქ არის საჭირო და იქიდან გადატანაც სჭირდება. და backup, რომელიც ბაზის იმავე დისკზე დევს, ცუდი DELETE-ისგან გიცავს და არა სერვერის დაკარგვისგან.

.bak-ის სერვერიდან გატანა#

backup, რომელიც ბაზის იმავე მანქანაზეა, ნახევარი backup-ია. ასლი სხვაგან გინდა, იდეალურად ისეთ ადგილას, რომელიც სერვერის წაშლას გადაურჩება. სამი რეალისტური გზა არსებობს:

1. ფაილის ჩამოტვირთვა. თუ ჰოსტი სერვერზე ფაილურ წვდომას გაძლევს, backup-ის დასრულების შემდეგ .bak SFTP-ით ჩამოიტანე და სერვერზე ძველები წაშალე. ეს ყველაზე მარტივი და ყველაზე პორტატული გზაა.
2. Backup პირდაპირ object storage-ში. SQL Server 2022-მა დაამატა BACKUP ... TO URL s3:// მისამართით S3-თავსებადი საცავისთვის, ავთენტიფიკაციით credential-ით, რომელიც access key-სა და secret-ს ინახავს. მას სჭირდება HTTPS endpoint, რომლის სერტიფიკატსაც სერვერი ენდობა, და სანამ დაეყრდნობი, შენს ედიციაზე გატესტვა ღირს.
3. ლოგიკური ექსპორტი. შენი მანქანიდან გაშვებული SqlPackage /Action:Export ჩვეულებრივი კავშირით .bacpac-ს ლოკალურად წერს. ის native backup-ზე ნელია და ტრანზაქციულად თანმიმდევრული არ არის, თუ ექსპორტის დროს ჩაწერები ხდება, მაგრამ სერვერზე ფაილურ წვდომას საერთოდ არ საჭიროებს.

RE:NODE-ზე SQL Server-ის ხაზი უშვებს SQL Server 2022 Express-ს Linux-ზე, ერთიდან ოთხამდე backup slot-ით, ტარიფის მიხედვით. პანელის backup-ები იღება მოთხოვნით ან განრიგით Schedules ჩანართიდან, ინახება იმ მანქანის გარეთ, რომელსაც იცავს, ჩამოიტვირთება და აღდგება ღილაკით - მაგრამ ისინი მთელი სერვერის ასლია და სერვერის წაშლა მათაც შლის. გონივრული სქემაა, შენი native BACKUP დაგეგმილი პანელის backup-მდე რამდენიმე წუთით ადრე გაუშვა, რომ არქივში ყოველთვის თანმიმდევრული .bak იყოს, და მათგან ერთი რეგულარულად ჩამოტვირთო ისეთ ადგილას, რომელიც მთლიანად შენია. ყოველ სერვერს ასევე აქვს SFTP და ფაილ მენეჯერი ფაილების პირდაპირ ჩამოსატანად. Backup-ები, რომლებიც მართლა აღდგება ხსნის, რატომ ვარდება ორი დამოუკიდებელი ასლი უკეთესად, ვიდრე ერთი კარგი.

Backup-ებისა და აღდგენის პრობლემების მოგვარება#

Operating system error 5 (Access is denied) ან error 2 (cannot find the file). გზას SQL Server-ის პროცესი ხსნის სერვერზე. Linux-ზე mssql მომხმარებელს დირექტორიაზე ჩაწერის უფლება სჭირდება, და დირექტორია უნდა არსებობდეს - BACKUP საქაღალდეებს არ ქმნის. Linux-ზე გზები რეგისტრს არჩევს, ამიტომ /var/opt/mssql/Data არ არის /var/opt/mssql/data.

Error 3154: backup set-ი შეიცავს არა არსებული, არამედ სხვა ბაზის backup-ს. ამ ბაზას სხვა ბაზის backup-ს ადებ. დაამატე REPLACE, თუ ეს მართლა ის არის, რაც გინდა, ან ახალი სახელით აღადგინე.

Error 3101: ექსკლუზიური წვდომის მიღება ვერ მოხერხდა, რადგან ბაზა გამოიყენება. რაღაც დაკავშირებულია - ხშირად შენივე query ფანჯარა. USE master, შემდეგ ბაზა გადაიყვანე SINGLE_USER WITH ROLLBACK IMMEDIATE-ზე, როგორც ზემოთაა ნაჩვენები.

Error 3169: ბაზის backup აღებულია სერვერზე, რომელიც უფრო ახალ ვერსიას უშვებს. ვერსიის წესი. ვერაფერი აიძულებს ამ .bak-ს, ძველ სერვერზე აღდგეს; გამოიყენე BACPAC ან სკრიპტები.

აღდგენა ჩავარდება, რადგან ბაზა 10240 MB-ს გადააჭარბებდა. Express თითოეული ბაზის მონაცემთა ფაილებს 10 GB-ით ზღუდავს. Standard-იდან უფრო დიდი ბაზის backup Express-ზე არ აღდგება. ჯერ წყაროზე დაარქივე ან წაშალე მონაცემები, ან გადადი ედიციაზე ამ ზღვრის გარეშე.

ბაზა "Restoring..." მდგომარეობაში გაიჭედა. აღდგენის ბოლო ნაბიჯმა NORECOVERY გამოიყენა. გაუშვი RESTORE DATABASE [appdb] WITH RECOVERY;, რომ ის ონლაინ გამოიყვანო.

FAQ#

შემიძლია SQL Server-ის ბაზის backup SSMS-იდან ჩემს კომპიუტერზე?

პირდაპირ არა. backup-ს სერვერის პროცესი წერს სერვერისავე დისკზე, მაშინაც კი, როცა SSMS-ის დიალოგს შენს ლეპტოპზე გადიხარ. backup სერვერზე აიღე და შემდეგ ფაილი ჩამოტვირთე, ან BACPAC-ის ექსპორტი გააკეთე, რომელსაც SqlPackage და SSMS ლოკალურ მანქანაზე წერს.

რამდენად ხშირად უნდა ავიღო backup პატარა SQL Server ბაზაზე?

ღამის full backup-ები აპლიკაციების უმეტესობას ფარავს, დამატებითი COPY_ONLY backup-ით ყოველი deploy-ის ან სქემის ცვლილების წინ. თუ ერთი დღის ჩაწერების დაკარგვა გეტკინება, დღის განმავლობაში differential-ები დაამატე ან გადადი full recovery model-ზე log backup-ებით ყოველ 15-დან 60 წუთამდე.

ბლოკავს BACKUP DATABASE ცხრილებს?

არა. კითხვა და ჩაწერა backup-ის დროს გრძელდება. ის დისკიდან კითხვას და გარკვეულ CPU-ს ხარჯავს, ამიტომ გაუშვი, როცა ბაზა მშვიდადაა, მაგრამ მომხმარებლები თავად backup-ისგან ბლოკირებას ვერ დაინახავენ. რამდენიმე ოპერაცია, მაგალითად ფაილის შეკუმშვა, backup-თან ერთდროულად ვერ გაეშვება.

შემიძლია Windows-ის SQL Server-ის backup-ის აღდგენა Linux-ის SQL Server-ზე?

დიახ. .bak ფორმატი ორივეზე იდენტურია. ლოგიკური ფაილის სახელების წასაკითხად გამოიყენე RESTORE FILELISTONLY, შემდეგ კი თითოეული ფაილი WITH MOVE-ით გადაიტანე Linux-ის გზაზე, მაგალითად /var/opt/mssql/data/. ვერსიის წესი მაინც მოქმედებს: მხოლოდ იგივე ან უფრო ახალი.

რატომ არის ჩემი Express backup ბაზის ზომისა?

იმიტომ, რომ Express შეკუმშულ backup-ებს ვერ წერს. ფაილი დაახლოებით დაკავებული გვერდების ზომისაა და არა გამოყოფილი ფაილის ზომისა. თუ საცავი ან გადატანის დრო მნიშვნელოვანია, ჩაწერის შემდეგ შეკუმშე gzip-ით ან zstd-ით; აპლიკაციის მონაცემების უმეტესობაზე დიდ შემცირებას მოელოდე.

არის .mdf და .ldf ფაილების ასლი ვალიდური backup?

მხოლოდ თუ კოპირებისას SQL Server გაჩერებული იყო ან ბაზა detach-ებული, და მაშინაც ის ამ ვერსიასა და ედიციაზეა მიბმული. გაშვებული სერვერიდან აღებული ასლი შეიძლება არ მიმაგრდეს. BACKUP DATABASE მხარდაჭერილი გზაა და დამატებით არაფერი ღირს.