Create the logins in the primary and grant them access to the log shipped db. On the secondary, you have to add the logins using the same SID.

Right, filegroup backups are not as straightforward. 🙂

With db size that big, you may also want to consider offloading checkdb execution on your online production database, by restoring your backups on a separate machine and running checkdb...

If you think all the necessary tasks have been executed properly for both 0 and 1 process exit codes, then consider them both successful.

You may want to script it...

I never tried it tho. But if I would, I'll try it out first on a dev somewhere, or look what sp_addserver/sp_dropserver really does, see if there's any dependent tables...

Have you tried sql jobs?

Full backups shouldn't break your log shipping.

Why would you want to update it? What are you trying?

I meant you ditch log restore, and go with dts, otherwise, you'll get the same changes as with your source database.

DTS

Then you'll have to script it out. Load the result of restore headeronly to a temp table, then query the position column.

Log shipping is the way to go if...

Man, can't believe I said to recover without tlog, that completely won't happen! I stand to be corrected..

Tho it's true that filegroup/file backup on occassion gets implemented on vldbs, it...

Use RESTORE LOG...WITH FILE =

If you look at the header information of your backup file (using RESTORE HEADERONLY), you take the file number from the POSITION column..the latest...

Not that I know. How about backing up to individual files to one location, then copy the latest to the other location deleting the old one?

Or, backup with noinit,...

I assume you already came accross an ugly solution that updates the system table...otherwise, you may need to call MS support.