Sql-server – Windows native backups makes SQL Server think that databases backup has been done

I would add TRY/CATCH blocks to handle errors and log them. The DB could be in single user, being restored or whatever.

Without this, errors can abort in a way that no errors are logged (statement, batch, scope, connection etc)

With TRY/CATCH then everything except for compile or connection aborting errors are logged? but I doubt this is the case.

I'd also use sys.databases which replaces sysdatabases and read more flags:

-- declares etc

BEGIN TRY

    DECLARE db_cursor CURSOR FOR  
    SELECT name, state, user_access
    FROM sys.databases 
    WHERE name NOT IN ('tempdb')

    OPEN db_cursor   
    FETCH NEXT FROM db_cursor INTO @name, @state, @user_access

    WHILE @@FETCH_STATUS = 0   
    BEGIN   

        SET @fileName = @path + @name + '.bak'
        IF @state = 0 AND user_access = 0
        BEGIN
            BEGIN TRY
                BACKUP DATABASE @name TO DISK = @fileName  WITH INIT
            END TRY
            BEGIN CATCH
                -- log but do not rethrow so loop continues
            END CATCH
            WAITFOR DELAY '00:00:20'
        END
        ELSE
           --log user and/or state issues

        FETCH NEXT FROM db_cursor INTO @name 
    END   

    CLOSE db_cursor   
    DEALLOCATE db_cursor

END TRY
BEGIN CATCH
  -- some useful stuff here
END CATCH

Backing up a database (BACKUP DATABASE ...) backs up the pages from all of the database files (data and log) and upon restore those files will be recreated as a result.

A full database backup does just that: It backs up the database in its entirety. There is no way to get around not backing up the transaction log file. If you are in full recovery mode, then you should ensure you are doing the proper transaction log backups so the log doesn't grow out of control. Outside of that, you are constrained with a full backup. A database consists of data file(s) and log file(s).

A workaround to this could be just to generate scripts from you database. When you right-click your database to generate scripts, you can script out the entire database. There is an option to script out both Schema and Data. Then on your other machine/instance you can run this script. It's not a traditional "backup" by any means, but it should get you what you want and you'll just have a script file as a result. Mind you, when the CREATE DATABASE portion of the script runs, a log file will be created. You can't have an RDBMS database without a log file (or at least not on SQL Server that I know of).